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Chapter  1 


Introduction 


This  dissertation  describes  a  type  system  for  supporting  runtime  type  analysis  in  a  certifying  com¬ 
piler.  Why  is  this  important  ?  Runtime  type  analysis  plays  a  crucial  role  in  many  applications,  and 
modern  language  implementations  arc  progressively  targeting  the  generation  of  certified  code.  The 
following  sections  show  how  runtime  type  analysis  plays  a  crucial  role,  and  why  it  is  important  to 
support  it  in  a  certifying  framework. 

1.1  Runtime  type  analysis 

Modern  programming  paradigms  arc  increasingly  giving  rise  to  applications  that  rely  critically  on 
type  information  at  runtime.  For  example: 

•  Java  adopts  dynamic  linking  as  a  key  feature,  and  to  ensure  safe  linking,  an  external  module 
must  be  dynamically  verified  to  satisfy  the  expected  interface  type. 

•  A  garbage  collector  must  keep  track  of  all  live  heap  objects,  and  for  that  type  information 
must  be  kept  at  runtime  to  allow  traversal  of  data  structures. 

•  In  a  distributed  computing  environment,  code  and  data  on  one  machine  may  need  to  be 
pickled  for  transmission  to  a  different  machine,  where  the  unpickler  reconstructs  the  data 
structures  from  the  bit  stream.  If  the  type  of  the  data  is  not  statically  known  at  the  destination 
(as  is  the  case  for  the  environment  components  of  function  closures),  the  unpickler  must  use 
type  information,  encoded  in  the  bit  stream,  to  correctly  interpret  the  encoded  value. 
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•  Type-safe  persistent  programming  requires  language  support  for  dynamic  typing:  the  pro¬ 
gram  must  ensure  that  data  read  from  a  persistent  store  is  of  the  expected  type. 

•  Finally,  in  polymorphic  languages  like  ML,  the  type  of  a  value  may  not  be  known  statically; 
therefore,  compilers  have  traditionally  used  inefficient,  uniformly  boxed  data  representation. 
To  avoid  this,  several  modern  compilers  use  runtime  type  information  to  support  unboxed 
data  representation. 

Existing  compilers  can  not  type-check  the  code  that  involves  runtime  type  inspections.  When 
compiling  such  code  they  use  untyped  intermediate  languages,  and  reify  runtime  types  into  values 
at  some  early  stage.  However,  discarding  the  type  information  during  compilation  makes  this 
approach  incompatible  with  certifying  compilation. 

1.2  Certifying  compilation 

A  certifying  compiler  [Nec98]  generates  not  only  the  object  code,  but  also  a  machine-checkable 
proof  that  the  code  satisfies  a  given  security  policy.  A  valid  proof  is  an  incontrovertible  certificate 
of  safety.  Both  the  code  and  the  proof  are  shipped  to  the  consumer.  Before  execution,  the  consumer 
checks  that  the  proof  is  correct  and  that  it  follows  logically  from  the  code. 

Code  certification  is  appealing  for  a  number  of  reasons.  If  a  compiler  can  generate  certified 
code,  we  no  longer  need  to  trust  the  correctness  of  the  compiler;  instead,  we  can  verify  the  correct¬ 
ness  of  the  generated  code.  Checking  a  compiler-generated  proof  is  much  easier  than  proving  the 
correctness  of  a  compiler.  Second,  with  the  growth  of  web-based  computing,  programs  and  ser¬ 
vices  arc  increasingly  being  developed  or  hosted  at  remote  sites,  and  then  downloaded  by  clients 
for  execution.  Client  programs  may  also  download  modules  dynamically  as  they  need  them.  In  a 
certifying  system,  clients  can  accept  code  from  untrusted  sources  and  verify  it  before  execution. 

Certified  compilation  is  simply  a  general  approach  for  applying  programming  language  tech¬ 
niques  for  constructing  secure  systems.  We  still  have  to  address  the  problem  of  constructing  a 
certifying  compiler.  How  does  one  arrange  for  a  compiler  to  generate  both  the  code  and  the  proof 
of  its  safety  ?  Morrisett  el  al.  [MWCG98]  showed  that  a  fully  type-preserving  compiler  is  a  prac¬ 
tical  basis  for  a  certifying  compiler.  Unlike  in  a  conventional  compiler,  a  type  preserving  com¬ 
piler  [Sha97b,  TMC+96]  does  not  discard  types  after  the  source  program  has  been  type-checked. 
Instead,  each  phase  propagates  the  type  information  so  that  the  code  finally  generated  by  the  com- 
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piler  can  be  type-checked.  The  safety  policy  enforced  is  type-safety,  and  the  proof  of  the  safety  lies 
in  the  type  annotations  in  the  generated  code. 

Therefore,  a  certifying  compiler  for  type  analyzing  applications  must  support  runtime  type 
analysis  in  a  type -preserving  framework.  This  dissertation  describes  a  type  system  that  makes  this 
possible.  The  following  sections  describe  two  key  features  included  in  the  type  system  for  writing 
certified  applications. 

1.3  Fully  reflexive  type  analysis 

Many  type-analyzing  applications  must  operate  on  arbitrary  runtime  values.  For  example,  a  pickier 
must  be  able  to  pickle  any  value  on  the  heap.  Similarly,  a  garbage  collector  must  be  able  to  traverse 
all  data  structures  on  the  heap  to  track  live  objects.  Therefore,  a  language  must  support  the  analysis 
of  the  type  of  all  runtime  values;  we  call  this  fully  reflexive  type  analysis. 

Supporting  type  analysis  in  a  type-safe  framework  has  been  an  active  area  of  research.  Previous 
researchers  in  type-directed  compilation  [HM95,  CW99]  have  designed  frameworks  for  runtime 
type  analysis.  Unfortunately,  none  of  these  frameworks  can  support  fully  reflexive  type  analysis. 
Consequently,  none  of  these  approaches  can  be  used  for  writing  type-analyzing  services  like  a 
garbage  collector.  Type-safe  services  like  garbage  collectors  arc  desirable  for  many  reasons.  First, 
the  security  of  a  computing  system  depends  on  the  safety  of  the  underlying  garbage  collector.  In 
existing  systems,  it  is  paid  of  the  trusted  computing  base  (TCB):  that  paid  of  the  code  that  is  assumed 
to  be  correct  and  remains  unverified.  Writing  it  in  a  type-safe  language  and  verifying  independently 
will  take  it  out  of  the  TCB.  This  makes  a  system  more  secure,  specially  because  these  services  arc 
often  complex  pieces  of  code  and  can  introduce  subtle  bugs.  Moreover,  a  type-safe  implementation 
would  make  the  interface  to  the  garbage  collector  explicit,  and  type-checking  could  then  ensure  that 
the  interface  is  always  respected. 

The  type  system  presented  in  this  dissertation  supports  fully  reflexive  type  analysis.  In  partic¬ 
ular',  it  supports  the  analysis  of  quantified  types  like  polymorphic  and  existential  types.  This  is  the 
first  work  that  shows  how  to  support  the  analysis  of  arbitrary  quantified  types.  We  also  show  that 
the  system  can  be  used  for  writing  a  type-safe  copying  garbage  collector.  Type  analysis  plays  the 
key  role  in  capturing  the  contract  between  the  mutator  and  the  collector. 
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1.4  Integrating  type  analysis  with  a  proof  system 


Existing  type -based  certifying  compilers  have  focussed  only  on  proving  conventional  type-safety 
properties  (like  simple  memory  and  control-flow  safety)  for  the  generated  code.  On  the  other 
hand,  the  concept  of  certifying  compilation,  as  pioneered  by  Necula  and  Lee  through  their  proof 
carrying  code  (PCC)  framework  [Nec98],  involves  a  logical  system  that  can  be  used  for  certi¬ 
fying  more  complex  specifications.  For  example,  the  foundational  proof  carrying  code  (FPCC) 
system  [AFOOb]  can  certify  any  property  expressible  in  Church's  higher-order  logic.  Type -based 
certifying  compilers  cannot  certify  properties  that  arc  as  general  because  the  type  systems  can  not 
match  the  expressiveness  of  the  logic  used  in  these  frameworks. 

One  of  the  challenges  then  in  type-based  certifying  compilation  is  to  come  up  with  type  systems 
that  can  be  used  for  certifying  more  advanced  properties  than  conventional  type-safety.  In  essence, 
we  want  to  express  logical  assertions  and  propositions  through  the  type  system. 

The  main  motivation  for  this  line  of  work  comes  from  the  close  relationship  between  logical 
systems  and  type  systems.  The  Curry- Howard  isomorphism  [How80]  (also  known  as  th eformula- 
as-types  principle)  shows  how  proofs  and  propositions  map  into  a  typed  lambda  calculus:  types 
represent  propositions  and  the  expressions  represent  proofs.  For  example,  a  proof  of  an  implica¬ 
tion  P  D  Q  can  be  considered  a  function  object:  it  is  a  function  that  when  applied  to  a  proof  of 
proposition  P  yields  a  proof  of  proposition  Q.  Most  type-based  proof  assistants  arc  based  on  this 
principle.  Barendregt  et  al.  [Bar99,  Bar91]  give  a  good  survey  of  previous  work  in  this  area. 

Accordingly,  in  Chapter  5,  we  show  a  type  system  that  integrates  type  analysis  with  the  explicit 
representation  of  proofs  and  propositions.  As  far  as  we  know,  our  work  is  the  first  comprehensive 
study  on  how  to  incorporate  higher-order  predicate  logic  and  runtime  type  analysis  into  a  single 
type  system  for  compiler  intermediate  languages.  Since  the  type  system  can  now  internalize  a  very 
expressive  logic,  formal  reasoning  traditionally  done  at  the  meta  level  can  now  be  expressed  inside 
the  actual  language  itself. 

1.5  Summary  of  contributions 

The  core  contribution  of  this  dissertation  is  a  type  system  for  analyzing  the  type  of  runtime  values, 
but  this  system  has  other  important  ramifications.  The  type  system  can  be  used  for  type-checking 
the  copy  function  in  a  stop-and-copy  garbage  collector,  and  thus  provides  a  significant  basis  for 
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writing  provably  type-safe  garbage  collectors.  The  underlying  ideas  can  also  be  used  for  integrating 
logical  assertions  in  a  type  system,  and  enforcing  more  sophisticated  invariants.  To  sum  up: 

•  We  show  the  design  of  a  type  system  that  supports  the  analysis  of  quantified  types,  both 
at  the  type  level  and  at  the  term  level.  We  prove  that  the  resulting  type  system  is  strongly 
normalizing  and  confluent.  We  also  show  an  encoding  of  the  calculus  in  a  type-erasure 
semantics.  We  prove  that  this  encoding  is  sound  by  establishing  a  correspondence  with 
reductions  in  an  untyped  language. 

•  We  show  that  this  type  system  can  be  applied  for  writing  the  copy  function  in  a  copying 
garbage  collector  in  a  type-safe  manner.  We  show  that  type-checking  this  function  relies 
crucially  on  the  ability  to  analyze  quantified  types,  like  existential  types.  We  prove  that  the 
language  in  which  the  copy  function  is  written  is  sound.  Our  formalization  does  exclude 
some  features  of  an  industrial-strength  collector,  nevertheless  it  represents  a  significant  step 
towards  designing  a  type  system  that  can  be  used  for  realistic  garbage  collectors. 

•  We  show  that  the  ideas  (underlying  the  analysis  of  quantified  types)  can  be  extended  to 
integrate  runtime  type  analysis  with  the  explicit  representation  of  logical  proofs  and  proposi¬ 
tions.  Again,  we  prove  that  the  resulting  type  system  is  strongly  normalizing  and  confluent, 
and  the  underlying  logic  is  consistent. 

•  We  show  empirically  that  the  type  system  can  be  used  in  an  industrial-strength  compiler.  For 
this,  we  implemented  the  system  in  an  experimental  version  of  the  SML/NJ  compiler  and 
compared  its  performance  with  version  1 10.34  of  the  compiler.  On  a  set  of  large  benchmarks, 
our  measurements  show  that  the  new  type  system  incurs  a  reasonable  compilation  overhead. 

1.6  Outline  of  this  dissertation 

In  Chapter  2  we  give  a  brief  overview  of  the  typed  lambda  calculi.  This  is  a  useful  introduction  for 
much  of  the  type-theoretic  work  presented  in  the  later  paid  of  the  dissertation.  Chapters  3  through  6 
constitute  the  core  of  this  dissertation.  In  Chapter  3,  we  show  in  detail  the  design  of  the  type  system 
for  fully  reflexive  type  analysis.  We  prove  its  meta-theoretic  properties  in  Appendix  A.  Chapter  4 
shows  how  this  type  system  can  be  applied  for  writing  a  type-safe  copying  garbage  collector.  The 
meta-theoretic  properties  of  the  languages  arc  proved  in  Appendix  B .  In  Chapter  5  we  show  how 
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the  type  system  can  be  augmented  to  explicitly  represent  and  manipulate  proofs  and  propositions. 
Appendix  C  proves  the  meta-theoretic  properties  of  this  type  system.  In  Chapter  6  we  describe  the 
implementation  of  the  type  system  in  an  experimental  version  of  the  Standard  ML  of  New  Jersey 
compiler.  We  also  compare  the  performance  of  our  implementation  to  that  of  the  SML/NJ  compiler 
(version  110.34)  on  some  large  benchmarks. 

History 

The  contents  of  Chapters  3  and  Appendix  A  arc  based  on  [STSOOb].  This  work  was  also  published 
as  [TSS00]  and  [STSOOa],  The  contents  of  Chapter  4  and  Appendix  B  arc  based  on  [MSS00]. 
This  work  was  also  published  as  [MSS01].  The  contents  of  Chapter  5  and  Appendix  C  arc  based 
on  [SSTP01].  This  work  was  published  as  [SSTP02]. 
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Chapter  2 


Overview  Of  The  Typed  Lambda 
Calculi 


In  this  chapter,  we  will  give  a  brief  overview  of  the  typed  lambda  calculi.  This  will  ease  the 
transition  to  the  type  systems  presented  later  in  the  dissertation.  The  typed  A-calculi  is  actually  an 
infinite  sequence  of  languages,  each  more  powerful  than  the  other.  The  sequence  starts  off  with 
the  simply-typed  lambda  calculus  and  culminates  in  Fw.  In  the  last  section  we  will  also  give  a 
brief  overview  of  the  Pure  Type  Systems.  We  will  show  how  a  Pure  Type  System  may  be  used  for 
modelling  many  of  these  typed  lambda  calculi,  and  even  type  systems  with  dependent  types.  There 
is  a  lot  of  excellent  literature  available  on  these  topics:  the  reader  may  refer  to  [PDM89,  Geu93, 
Bar91]. 

2.1  The  simply  typed  lambda  calculus 

The  pure  simply  typed  lambda  calculus,  also  called  F\,  may  be  defined  as  in  Figure  2.1.  Here  r  is 
the  set  of  types,  e  is  the  set  of  terms,  x  ranges  over  variables.  Ax :  t.  e  is  a  lambda  term,  and  e  e'  is 
an  application.  In  the  term  Ax :  r.  e,  the  variable  x  is  the  bound  variable  in  the  function  body  e. 

(types)  t  ::=  t->t' 

(terms)  e  ::=  x  |  A x:r.  e  |  ee' 

Figure  2.1:  Syntax  of  F\ 
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(prog) 

P 

::=  De  \  DP 

(ind) 

D 

::=  Ind  I  with  (C) 

(constr) 

C 

::=  x:t  x:t;C 

(types) 

T 

::=  I  t  — >  t' 

(terms) 

e 

::=  x  Xx:r.e 

Figure  2.2:  Syntax  of  F{ 


The  reduction  rule  is  the  /3-reduction  where  the  bound  variable  is  substituted  by  the  argument 
in  the  function  body:  (Ax :  r.  e)  e!  ^  [e'/x]e. 

Unfortunately,  the  language  above  is  not  very  useful  since  the  set  of  types  is  empty.  To  make 
it  practical  we  need  some  mechanism  of  introducing  primitive  types  and  operations  over  these 
types.  We  could  introduce  some  primitives  in  an  ad-hoc  manner,  but  we  would  rather  use  a  general 
mechanism.  This  brings  us  to  F{  (Figure  2.2)  which  is  F\  augmented  with  a  general  facility  for 
introducing  inductively  defined  types.  Here  P  is  a  program,  I)  is  an  inductive  definition,  C  arc  the 
constructors  of  an  inductive  definition,  and  I  is  the  name  for  an  inductively  defined  type. 

For  example,  we  can  define  the  natural  numbers  and  the  booleans  as: 

Ind  Nat  with  (zero:  Nat;  succ:  Nat  — »  Nat) 

Ind  Bool  with  (true:  Bool;  false:  Bool) 

Associated  with  each  inductive  definition  is  an  iterator.  The  iterator  takes  a  set  of  functions 
corresponding  to  each  constructor  of  an  inductive  definition  I,  a  value  of  type  I,  and  performs 
structural  induction  over  the  value.  For  example,  an  iterator  over  the  natural  numbers  (iter Nat  ) 
would  behave  as  follows: 


iter  Amt  zero  z  s^-  z 

iter  Nat.  (succ  e)  z  S  S  (iter  Nat  ez  s) 

The  iterator  can  be  used  to  implement  all  the  ordinary  primitive  recursive  functions  over  natural 
numbers,  like  addition.  Note  that  the  iterator  can  return  a  value  of  any  type.  In  essence,  an  induc¬ 
tively  defined  type  generates  an  infinite  set  of  iterators,  one  for  each  return  type.  To  ensure  that  the 
language  still  remains  terminating,  we  need  to  constrain  the  definition  of  inductive  types  suitably. 
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Definition  2.1.1  The  set  of  positively  occuring  variables  Pos(r)  is  defined  as: 

Pos(7)  =  7 

Pos(t  — >  t')  =  Neg(r)  +  Pos(r') 

Neg(J)  =  f 

Neg(r  — >  t')  =  Pos(r)  +  Neg(r') 

In  an  inductive  definition,  the  defined  type  can  occur  only  positively  in  the  type  of  the  arguments 
to  the  constructors.  Formally,  an  inductively  defined  type  I  is  shown  below.  Here  the  Xi  are  the 
constructors.  The  defined  type  I  occurs  positively  in  the  riy . 

Ind  I  with 

x\  :rn  — *■  T12  -+  •  •  •  ->•  7; 
x2:t2i  ->  r22  7; 


Xn  :  Tn  1  >  Tn 2  >  . . .  >7 

Each  such  definition  generates  an  iteration  scheme  iter/  with  an  instance  of  the  iterator  for 
every  type  r.  The  iterator  takes  a  value  of  type  7,  a  function  for  every  constructor  of  7,  and  returns 
a  result  of  type  r.  The  type  of  the  iterator  is: 


iter/:  7 


On  - 

n2  ->  •  • 

•  ->  t) 

(Tn  - 

+  T2 2  — >•  •  • 

■  ->  r) 

(Tn  - 

*  Tn2  ■ 

.  .  T 

T 

Here  Tfj  is  equivalent  to  tvj  with  7  replaced  by  r.  Functionally,  the  iterator  takes  a  term  of  type 
7,  walks  over  its  structure,  and  replaces  every  constructor  with  the  function  corresponding  to  that 
constructor.  In  addition,  it  also  recursively  processes  the  arguments  of  the  constructor.  Expressed 
as  a  reduction  rule,  this  is  equivalent  to: 


it©r J  ( Xi  en  .  .  .  Cim)  tq  •  •  •  •  •  ■  (‘nn) 

where  xr  is  the  ith  constructor  of  7,  er)  arc  its  arguments,  e-  is  the  function  coiTesponding  to  the 
ith  constructor,  and  efj  is  the  result  of  recursively  processing  the  argument:  that  is  replacing  every 
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(types)  t  ::=  r  — >  t'  \  a  \  \/a:ft.T 

(terms)  e  ::=  x  |  A x:r.e  \  ee'  |  A cr.Q.e  |  e  [r] 

Figure  2.3:  Syntax  of  F2 


subterm  e  of  type  I  with  iter/T  e  e\  . . .  e'n. 

The  key  point  about  F\  is  that  all  programs  are  terminating  and  that  all  reduction  sequences 
are  confluent. 

2.2  The  polymorphically  typed  lambda  calculus 

The  problem  with  F[  is  that  there  is  no  way  to  parametrize  a  function  over  the  type  of  its  arguments. 
For  example,  we  can  define  the  identity  function  over  the  natural  numbers  as  follows: 

id  Nat  =  A  x:Nat.x 

But  the  identity  function  makes  sense  for  values  of  other  types  as  well.  In  F{  we  have  to  repeat  the 
definition  for  every  instance  at  which  we  want  to  use  it.  Instead  what  we  would  like  is  a  mechanism 
to  abstract  the  type  of  the  arguments  and  then  instantiate  the  type  when  we  actually  use  the  function. 
The  identity  function  would  now  look  like: 

id  =  Act :  12.  A.x :  a.  x  idNat  =  id  [Nat] 

This  says  that  the  first  argument  to  the  identity  function  is  a  type.  When  this  function  is  used,  the 
type  is  passed  as  an  explicit  argument.  We  also  say  that  the  identity  function  is  polymorphic  since 
it  can  take  arguments  of  any  type.  This  brings  us  to  the  polymorphically  typed  lambda  calculus,  or 
F-2  [Gir72,  Rey74].  The  syntax  for  F2  is  shown  in  Figure  2.3. 

At  the  type  level,  we  have  a  new  construct  (Va :  fi.  r)  to  type  polymorphic  functions.  For  now, 
consider  the  Q  classifier  to  be  a  syntactic  artifact.  The  typing  rule  for  polymorphic  functions  and 
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type  applications  says: 


A,a:f);r  F  e:r  a  £  A  A;T  h  eiVaiH.r 

A;  T  F  Aa:f).  e:Va:n.  r  A;  T  F  e  [r'] :  [r'/a]r 

Here  A  is  the  environment  that  keeps  track  of  free  type  variables.  F  is  the  value  environment;  it 
maps  a  variable  to  its  type.  For  example,  the  identity  function  now  has  the  type  Va :  f).  a  — ►  a. 

2.2.1  Encoding  F\  inductive  definitions  in  F-> 

If  we  examine  the  type  calculus  of  F-2  (Figure  2.3),  then  again  the  definition  does  not  contain 
any  primitive  types.  However,  unlike  in  F\,  we  do  not  need  to  add  a  mechanism  for  introducing 
primitive  types  and  operations  over  these  types.  Instead,  Bohm  and  Berarducci  [BB95]  proved  that 
we  can  encode  all  of  the  inductive  types  of  F\  and  the  associated  iteration  operators  in  F>. 

As  an  example  we  will  consider  the  encoding  of  the  natural  numbers.  Suppose  the  inductive 
type  Nat  is  given  the  closed  type 

Nat  =  Va :  f).  a  — >  (a  — >  a)  — >  a 

Nat  takes  two  arguments,  one  of  them  representing  zero  and  the  other  representing  the  successor 
of  a  natural  number.  Instances  of  the  natural  numbers  now  have  the  following  term  representation: 

0  =  Aa :  fk  Xx :  a.  A/ :  a  — ►  a.  x 

1  =  Aa :  fk  Xx :  a.  Xf :  a  — ►  a.  /  x 

2  =  Aa :  H.  Xx :  a.  Xf :  a  — >  a.  /  (/  x) 


The  key  idea  is  that  the  term  representation  of  the  natural  numbers  captures  the  structure  of  the 
corresponding  induction  in  F{.  We  said  in  F{  that  an  iterator  can  return  a  value  of  any  type.  Since 
we  want  to  capture  iteration  as  well,  we  give  Nat  a  polymorphic  type.  When  we  are  iterating  over 
natural  numbers,  Nat  will  be  instantiated  to  the  return  type.  In  essence,  the  F2  representation  of 
a  FI  inductive  value  serves  as  its  own  iterator.  In  /V  the  iterator  over  natural  numbers  has  the 
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following  form: 


iter^a/  n  =  n  [r] 

Here  n  is  a  number  defined  inductively  in  F{,  while  n  is  its  representation  in  F2. 

We  know  that  F2  is  powerful  enough  to  define  the  primitive  recursive  functions,  but  actually 
we  can  define  more.  In  particular,  we  can  also  define  Ackermann’s  function  in  F2.  However,  F2 
still  remains  a  strongly  normalizing  language:  we  cannot  express  non-terminating  computations  in 
F2.  Moreover,  all  reduction  sequences  in  F2  are  confluent. 


2.2.2  Adding  inductive  types  to  F2 

We  could  still  go  ahead  and  add  a  mechanism  for  adding  inductively  defined  types  to  F2.  Unlike 
in  F\,  the  constructors  can  now  have  polymorphic  types.  But  as  in  the  previous  case,  F\  can  be 
encoded  in  F:>.  the  next  language  in  the  hierarchy.  In  fact.  Pfenning  [Pfe88]  proved  that  inductively 
defined  types  with  polymorphic  constructors  in  the  nth  order  A-calculus  can  be  translated  into  the 
pure  (n  +  l)th  order  A-calculus. 

However,  with  the  addition  of  polymorphic  types  we  need  to  redefine  the  notion  of  positive  and 
negative  occurrences. 

Definition  2.2.1  The  set  of  positively  occuring  variables  Pos(r)  is  defined  as: 

Pos(a)  =  a 

Pos(t  — >  t')  =  Neg(r)  +  Pos(r') 

Pos(Va:H.r)  =  Pos(r) 


Neg(a)  =  <f> 

Neg(r  — r  t')  =  Pos(r)  +  Neg(r') 

Neg(Va:H.r)  =  Neg(r) 

2.3  The  third  order  lambda  calculus 

Suppose  we  wanted  to  represent  type  constructors  in  our  language.  Let  us  consider  the  Vector 
type.  The  type  Vector  is  in  itself  not  the  type  of  any  object.  We  need  to  apply  it  to  another  type 
before  we  get  something  that  is  the  type  of  an  object;  for  example,  a  vector  of  integers.  Therefore, 
a  vector  is  a  form  of  a  type  constructor,  or  a  function  from  types  to  types.  Programming  languages 
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(i kinds ) 

k  :: 

=  n 

I  n- 

->  K 

{types) 

r  :: 

=  T  ~ 

->  t' 

1  Q 

Vcc: 

K.  T 

(terms) 

e  :: 

=  X 

Xx: 

r.  e 

ee' 

|  Aa 

Figure  2.4:  Syntax  of  Fj 


(kinds) 

k  :: 

=  n 

1  K  ~ 

-r  k' 

(types) 

r  :: 

=  T  - 

->  t' 

a 

Va: 

K.  T  | 

(terms) 

e  :: 

=  X 

Xx: 

t.  e 

ee' 

|  Aa 

Figure  2.5:  Syntax  of  F^ 


have  many  examples  of  type  constructors,  for  example  Array  and  List.  We  can  define  a  particular 
instance  of  the  List  constructor  in  F-p,  for  example,  we  could  define  a  list  of  integers.  But  if  we 
then  needed  a  list  of  booleans,  we  would  have  to  define  a  new  type.  Instead,  what  we  would  like  is 
to  define  a  List  type  constructor,  and  then  create  different  instances  from  this  constructor. 

This  brings  us  to  Fj  where  we  add  the  ability  of  express  functions  from  types  to  types.  The 
syntax  is  shown  in  Figure  2.4.  We  denote  type  functions  with  a  similar  syntax  to  the  term  functions. 
We  use  r  t'  to  denote  the  application  of  a  type  r  to  another  type  t'  .  However,  since  we  introduced 
functions  at  the  type  level,  we  need  some  mechanism  for  ensuring  that  our  types  are  well-formed. 
For  this  we  add  a  new  layer  that  we  call  kinds.  In  essence,  kinds  are  the  “types”  of  types.  We  have 
a  constant  kind  that  we  call  H.  This  is  the  kind  of  the  types  of  terms,  for  example  the  types  r  — >  r' 
and  Va :  n.  r  belong  to  Q.  A  type  function  (Aa :  Q.  r)  has  the  function  kind  (Q  — >  n). 

As  before,  Fj  is  also  a  strongly  normalizing  language  with  all  reductions  being  confluent. 

2.4  The  uj  order  lambda  calculus 

From  Fj,  we  get  to  the  languages  F4,  F5,  etc  by  making  the  set  of  legal  kinds  larger.  In  other 
words,  while  Fj  allows  only  first  order  type  constructors,  these  languages  allow  higher  order  type 
constructors.  In  the  limit  we  reach  Fu  where  the  kinds  are  completely  general.  The  syntax  of  F^ 
is  shown  in  Figure  2.5. 
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has  a  number  of  interesting  properties: 

•  All  expressions  (terms,  types,  and  kinds)  in  have  a  unique  normal  form. 

•  FJ'  =  Fw.  Inductive  type  definitions  whose  constructors  have  types  in  Fu  can  be  translated 
into  closed  types  in  F^. 

•  Fn  can  express  all  functions  whose  totality  is  provable  in  nth  order  arithmetic  [Gir88]. 


2.5  Pure  type  systems 

An  alternative  method  of  describing  the  typed  lambda  calculi  is  through  the  framework  of  Pure 
Type  Systems  (PTS).  This  is  a  general  framework  that  can  capture  a  large  class  of  typed  lambda 
calculi.  In  this  section,  we  give  a  short  tutorial  on  PTS  using  a  very  small  expression  language. 
The  reader  may  refer  to  [Bar91]  for  details.  The  syntax  of  PTS  pseudo-terms  is 

( pseudo-terms )  A,  B  ::=  c  \  X  \  XX :  A.  B  \  A  B  \  HX :  A.  B 

and  the  semantics  is  based  on  the  usual  notion  of  f5  reduction: 

(XX:  A.  B)  A'  [A'/X\B 

The  first  four  productions  in  the  syntax  are  familial- — they  are  constants  c  drawn  from  a  set  C,  vari¬ 
ables,  abstractions,  and  applications.  The  language  is  explicitly  typed:  The  abstraction  has  a  type 
annotation  for  the  bound  variable.  Note  that  this  type  annotation  is  again  an  expression,  in  other 
words,  types  and  terms  share  the  same  syntax.  Moreover,  the  same  productions  form  abstraction 
and  application  for  both  terms  and  types.  For  example,  consider  the  following  expression  in  F2 

Aa:S7.  Ax:  a.  id  [a]  x 

In  the  above  expression,  17  is  a  kind,  the  A  binds  a  type  variable  a  of  kind  17,  the  A  binds  a  term 
variable  x  of  type  a.  In  the  body  of  the  function,  the  polymorphic  identity  function  is  first  applied 
to  the  type  variable  a  and  then  to  the  term  variable  x.  In  contrast,  in  our  PTS,  the  above  expression 
would  be  written  as 

xx-.n.xx'-.x.  (id  x)  x' 
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The  II  production  is  a  key  feature  and  subsumes  both  function  and  polymorphic  types.  In  fact, 
it  is  the  only  type  forming  operator  in  the  language.  Intuitively  the  term  IT  A" :  A.  B  is  the  type  of 
functions  from  values  of  type  A  to  values  of  type  B.  Moreover,  the  type  B  may  depend  on  the 
value  of  the  argument.  It  is  obvious  that  II  subsumes  the  function  type 

A->B  =  U_:A.B 


Now  consider  the  expression  II X  :  fi.  A.  This  is  the  type  of  functions  from  values  of  type  O 
to  values  of  type  A  where  X  may  occur  free  in  A.  But  this  is  precisely  the  meaning  of  the  type 
Va :  IT  A1  in  F-2  (with  A'  =  [a/ X]  A). 

We  use  a  type  system  to  define  the  well  formed  expressions — in  turn,  the  type  system  relies  on 
a  specification. 


Definition  2.5.1  The  specification  of  a  PTS  is  a  triple  (S,  A,  1Z)  where 

•  S  C  C  is  called  the  set  of  sorts 

•  ACC  x  S  is  a  set  of  axioms 


•  TICS  x  S  x  S  is  a  set  of  rules. 


We  will  use  (si,  s 2)  as  an  abbreviation  for  elements  of  TZ  of  the  form  (si,  S'2,  S2).  In  the  rest  of  this 
section  we  will  only  consider  these  simpler  PTSs:  these  arc  sufficient  to  describe  the  type  systems 
of  interest  to  us.  We  will  also  use  s  to  denote  any  particular  sort.  The  formation  rules  for  terms  of 
the  PTS  ( S ,  A,  TT)  are  as  follows. 


(c,  s)  e  A 
h  c  :  s 


(AX) 


A  h  A  :  s 
A, AAA  h  X  :  A 


(VAR) 


Ah  A:  B  Ah  C  :  s 
A,X:C  h  A  :  B 

A  h  A  :  HX:B'.  A'  Ah  B  :  B' 

A  h  A  B  :[B/X]A' 

A,X:A  h  B  :  B’  A\rUX:A.B':s 
A  h  XX:A.B  :  UX  :A.B' 


(WEAK) 


(APP) 


(FUN) 
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A  b  A  :  si  A,  X :  A  h  B  :  S2  (si, s2)  €  7Z 
A  h  n X:A.B  :  s2 


(PROD) 


Ah  A:  B  Ah  B'  :  s  B  =p  B' 
A  h  A  :  B' 


(CONV) 


The  first  three  rules  arc  fairly  straightforward.  The  AX  rule  merely  specifies  the  sorts  and  the  rela¬ 
tion  between  them.  In  the  VAR  and  the  WEAK  rules,  we  ensure  that  the  type  of  the  variable  is  well 
formed.  The  APP  rule  is  more  interesting.  Note  that  in  the  type  for  A,  the  variable  X  can  occur 
free  in  the  body  A'\  therefore,  the  result  type  is  obtained  by  substituting  for  the  variable  X.  In  the 
special  case  of  an  arrow  type,  the  variable  X  does  not  occur  free  in  the  body  A1.  Therefore,  the 
substitution  has  no  effect  and  the  typing  derivation  reduces  to  the  usual  rule  for  function  applica¬ 
tion.  Moreover,  the  rule  is  sufficient  for  dealing  with  type  applications.  Consider  the  rule  for  type 
application  in  F2  that  we  saw  before: 


A;  T  h  e:  Va:fl.  r 
A;  T  h  e  [t']  :  [r'/a]r 

The  APP  rule  is  equivalent  to  the  above  rule  when  we  consider  that  the  polymorphic  type  Va :  ft.  r 
can  be  written  as  a  product  type  HX :  ft.  A,  and  there  is  only  a  single  syntactic  category  of  terms. 

The  FUN  and  the  CONV  rule  hold  no  new  surprises.  The  equality  in  the  CONV  rule  is  defined 
as  the  reflexive,  symmetric  and  transitive  closure  of  the  one  step  reduction  A-  The  PROD  rule 
describes  when  a  II  expression  is  a  valid  type.  The  PTS  contains  as  many  copies  of  this  rule  as 
there  are  members  in  the  set  71.  Through  this  rule,  the  set  1Z  specializes  the  PTS  to  a  particular 
type  system. 

Suppose  we  specialize  a  PTS  to  the  following  specification: 

S  =  (fl,  Kind)  A  =  (f2,  Kind)  X  =  {{ fl,fl)} 

In  the  PROD  rule,  both  A  and  B  must  belong  to  ft  which  means  that  they  are  both  types.  This 
implies  (from  the  FUN  rule)  that  we  can  abstract  a  term  variable  over  a  term  expression.  Since  this 
is  the  only  kind  of  abstractions  that  we  arc  allowed  to  construct,  essentially  we  have  the  simply 
typed  lambda  calculus. 
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Consider  the  PTS  with  the  following  specification: 


S  =  (fi,  Kind)  A  =  (fi,  Kind)  K  =  {(fi,fi),  (Kind,  r^)} 

We  will  now  have  two  instances  of  the  PROD  rule.  Specializing  to  (Kind,  Q)  we  get 

A  b  A  :  Kind  A,X:A  h  B:Sl 
A  F  UX:A.B  :  Q 

This  means  that  A  is  a  kind  and  B  is  a  type;  which  implies  that  A  is  a  type  variable.  In  other  words, 
we  now  have  a  polymorphic  type.  Correspondingly,  we  now  also  have  polymorphic  abstractions  in 
addition  to  term  abstractions.  Therefore,  the  above  specification  describes  the  system  F-2- 

Before  closing  this  section,  we  would  like  to  show  how  a  PTS  can  also  specify  systems  with 
dependent  types.  Consider  adding  the  pair  (fi,  Kind)  to  1Z. 

A  h  A,X:A  h  B'  :  Kind 

A  b  UX-.A.B'  :  Kind 

A,X:A\-B:B'  A  b  UX:A.  B'  :  Kind 
A  h  XX-.A.B  :  UX:A.B' 

In  the  PROD  rule,  B'  is  a  kind  while  A  is  a  type,  and  A  is  a  term  variable.  In  the  FUN  rule,  since 
IIA  :  A.  B’  is  a  kind,  the  abstraction  is  a  function  at  the  type  level.  But  this  function  expects  a 
term  level  expression  as  an  argument.  Hence,  the  value  of  this  type  expression  depends  on  a  term 
expression  which  implies  that  we  are  in  the  realm  of  dependent  types. 

The  following  table  lists  some  type  systems  that  arc  instances  of  a  PTS  with  the  above  S  and 
A.  They  form  part  of  what  is  popularly  called  the  A-cube. 


System 

n 

simply  typed  A-calculus 

F-2 

Calculus  of  constructions 

(n,n) 

(Kind,H) 

(H,  H),  (Kind,  H),  (Kind,  Kind) 

(H,  H),  (Kind,  H),  (Kind,  Kind),  (H,  Kind) 
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Chapter  3 


A  Language  For  Runtime  Type  Analysis 

3.1  Introduction 

Runtime  type  analysis  is  used  extensively  in  various  applications  and  programming  situations. 
Runtime  services  such  as  garbage  collection  and  dynamic  linking,  applications  such  as  marshalling 
and  pickling,  type-safe  persistent  programming,  and  unboxing  implementations  of  polymorphic 
languages  all  analyze  types  to  various  degrees  at  runtime.  Most  existing  compilers  use  untyped 
intermediate  languages  for  compilation;  therefore,  they  support  runtime  type  inspection  in  a  type- 
unsafe  manner. 

This  chapter  presents  a  statically  typed  intermediate  language  that  allows  runtime  type  analysis 
to  be  coded  within  the  language.  Therefore,  it  can  be  used  to  support  runtime  type  analysis  in 
a  type-safe  manner.  The  system  presented  here  builds  on  existing  work  [HM95]  but  makes  the 
following  new  contributions: 

•  It  supports  fully  reflexive  type  analysis  at  the  term  level.  Consequently,  programs  can  analyze 
any  runtime  value  such  as  function  closures  and  polymorphic  data  structures. 

•  It  supports  fully  reflexive  type  analysis  at  the  type  level.  Therefore,  type  transformations 
operating  on  arbitrary  types  can  be  encoded  in  our  language. 

•  We  prove  that  the  language  is  sound  and  that  type  reduction  is  strongly  normalizing  and 
confluent. 

•  We  show  a  translation  into  a  type  erasure  semantics. 
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By  fully  reflexive  we  mean  that  type  analyzing  operations  arc  applicable  to  the  type  of  any 
runtime  value  in  the  language.  In  particular,  the  language  provides  both  type-level  and  term-level 
constructs  for  analyzing  quantified  types  such  as  polymorphic  and  existential  types. 

3.2  Background 

Harper  and  Morrisett  [HM95]  proposed  intensional  type  analysis  and  presented  a  type-theoretic 
framework  for  expressing  computations  that  analyze  types  at  runtime.  They  introduced  two  explicit 
type-analysis  operators:  one  at  the  term  level  (typecase)  and  another  at  the  type  level  (Typerec); 
both  use  induction  over  the  structure  of  types.  Type-dependent  primitive  functions  use  these  op¬ 
erators  to  analyze  types  and  select  the  appropriate  code.  For  example,  a  polymorphic  subscript 
function  for  arrays  might  be  written  as  the  following  pseudo-code: 

sub  =  A  a:  Cl.  typecase  a  of 
int  =>intsub 
real  =>  realsub 
(3  =>  boxedsub  [f3] 

Here  sub  analyzes  the  type  a  of  the  array  elements  and  returns  the  appropriate  subscript  function. 
We  assume  that  arrays  of  type  int  and  real  have  specialized  representations  (defined  by  types,  say, 
intarray  and  realarray),  and  therefore  special  subscript  functions,  while  all  other  arrays  use  the 
default  boxed  representation. 

Typing  this  subscript  function  is  more  interesting,  because  it  must  have  all  of  the  types 
intarray  — ■>  int  — >  int,  realarray  — >  int  — *  real,  and  Va  :  fl.  boxedarray  (a)  — >  int  — *  a. 

To  assign  a  type  to  the  subscript  function,  we  need  a  construct  at  the  type  level  that  parallels  the 
typecase  analysis  at  the  term  level.  In  general,  this  facility  is  crucial  since  many  type-analyzing 
operations  like  flattening  and  marshalling  transform  types  in  a  non-uniform  way.  The  subscript 
operation  would  then  be  typed  as 
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(kinds)  k  ::=  ff  |  k  — >  k' 

(cons)  t  ::=  int  |  r  — >  t'  \  a  \  Xct.k.t  |  rr' 

|  Typerecrof  (rint;  T_^) 

(types)  a  ::=  r  |  Vcc.k.ct 

Figure  3.1:  The  type  language  of  Harper  and  Morrisett 


:  Va  :  ft.  Array  (a)  — >  int  — ►  a 

=  A a  :  Q. Typecase  a  of 
int  =>  intarray 
real  =»  realarray 
/ 3  =»  boxedarray  (3 

The  Typecase  construct  in  the  above  example  is  a  special  case  of  the  Typerec  construct  in  [HM95], 
which  also  supports  primitive  recursion  over  types. 

3.2.1  The  problem 

The  language  of  Harper  and  Morrisett  splits  the  type  language  into  two  universes,  constructors  and 
types  (Figure  3.1),  with  the  constructors  containing  just  the  monotypes.  Type  analysis  is  restricted 
to  the  constructors;  they  do  not  support  analysis  of  types  with  binding  structure  (e.g.,  polymorphic, 
or  existential  types).  Therefore,  type  analyzing  primitives  that  handle  polymorphic  code  blocks, 
or  closures  (since  closures  are  represented  as  existentials  [MMH96]),  cannot  be  written  in  their 
language.  The  constructor-kind  calculus  (Figure  3.1)  is  essentially  a  simply  typed  lambda  calculus 
augmented  with  the  constant  O.  The  Typerec  operator  analyzes  only  constructors  of  kind  il: 

int  :  H 

->  :  n  — >  n  -» n 

The  kinds  of  these  constructors’  arguments  do  not  contain  any  negative  occurence  (Section  2.1)  of 
the  kind  O,  so  int  and  — >  can  be  used  to  define  Q  inductively.  The  Typerec  operator  is  essentially 


sub 

where  Array 
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an  iterator  over  this  inductive  definition;  its  reduction  rules  can  be  written  as: 


Typerec  int  of  (rint;  t_>)  rint 

Typerec  (n  ->  r2)  of  (rint;  r_^) 

T— >  ri  r2  (Typerec  n  of  (rint;  t_>))  (Typerec  r2  of  (rint;  r_>)) 

Here  the  Typerec  operator  examines  the  head  constructor  of  the  type  being  analyzed  and  chooses 
a  branch  accordingly.  If  the  type  is  int,  it  reduces  to  the  Tint  branch.  If  the  type  is  t\  — >  r2,  the 
analysis  proceeds  recursively  on  the  subtypes  n  and  r2.  The  Typerec  operator  then  applies  the 
r_^  branch  to  the  original  component  types,  and  to  the  result  of  analyzing  the  components;  thus 
providing  a  form  of  primitive  recursion. 

Types  with  binding  structure  can  be  constructed  using  higher-order  abstract  syntax.  For  exam¬ 
ple,  the  polymorphic  type  constructor  V  can  be  given  the  kind  (H  — >  H)  — >  Q,  so  that  the  type 
Va  :  Q.  a  — >  a  is  represented  as  V  (Aa  :  fi.  a  — >  a).  It  would  seem  plausible  to  define  an  iterator 
with  the  reduction  rule: 


Typerec  (Vr)  of  (rint;  r_^;  rv) 

^  r\/ r  (Aa:H.  Typerec  r  a  of  (rint;  r_^;  t\j)) 

However  the  negative  occurence  of  Q  in  the  kind  of  the  argument  of  V  poses  a  problem:  this  iterator 
may  fail  to  terminate!  Consider  the  following  example,  assuming  r  =  A  a  :  H.  a  and 

T\/  =  A/?i : H  — >  H.  A/32 : — >  fl.  /?2  (V/3i) 

the  following  reduction  sequence  will  go  on  indefinitely: 

Typerec  (Vr)  of  (rint;  t_^;  rv) 

rv r  (Aa : fi.  Typerec  ra  of  (Tint;  t_^;  tv)) 

Typerec  (t(Vt))  of  (Tint;  t^;  tv) 

Typerec  (Vt)  of  (Tint;  t_^;  tv) 


Clearly  this  makes  typechecking  Typerec  undecidable. 

Another  serious  problem  in  analyzing  quantified  types  involves  both  the  type-level  and  the 
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term-level  operators.  Typed  intermediate  languages  like  FLINT  [Sha97b]  and  TIL  [Tar96]  arc 
based  on  the  Fu  calculus  [Gir72,  Rey74],  which  has  higher  order  type  constructors.  In  a  quantified 
type,  say  3/3 :  k.  t,  the  quantified  variable  /3  is  no  longer  restricted  to  the  base  kind  17,  but  can  have 
an  arbitrary  kind  k.  Consider  the  term-level  typecase  in  such  a  scenario: 

sub  =  Aa  :  17.  typecase  a  of 

int  =y-  Cint 

3/3 :  k.  t  =y-  eg 

To  do  anything  useful  in  the  e 3  branch,  even  to  open  a  package  of  this  type,  we  need  to  know  the 
kind  k.  We  can  get  around  this  by  having  an  infinite  number  of  branches  in  the  typecase,  one 
for  each  kind;  or  by  restricting  type  analysis  to  a  finite  set  of  kinds.  Both  of  these  approaches  are 
clearly  impractical.  Recent  work  on  typed  compilation  of  ML  and  Java  has  shown  that  both  would 
require  an  F^-like  calculus  with  arbitrarily  complex  kinds  [Sha98,  Sha99,  LST99]. 

3.2.2  Requirements  for  a  solution 

Before  getting  to  the  solution,  we  will  enumerate  the  properties  that  it  should  have. 

First,  our  language  must  support  type  analysis  in  the  manner  of  Harper/Morrisett.  That  is,  we 
want  to  include  type  analysis  primitives  that  will  analyze  the  entire  syntax  free  representing  a  type. 
Second,  we  want  the  analysis  to  continue  inside  the  body  of  a  quantified  type;  handling  quantified 
types  parametrically,  or  in  a  uniform  way  by  providing  a  default  case,  is  insufficient.  As  we  will 
see  later,  many  interesting  type-directed  operations  require  these  two  properties.  Third,  we  do  not 
want  to  restrict  the  kind  of  the  (quantified)  type  variable  in  a  quantified  type;  we  want  to  analyze 
types  where  the  quantification  is  over  a  variable  of  arbitrary  kind. 

Consider  a  type-directed  pickier  that  converts  a  value  of  arbitrary  type  into  an  external  rep¬ 
resentation.  Suppose  we  want  to  pickle  a  closure.  With  a  type -preserving  compiler,  the  type  of 
a  closure  would  be  represented  as  an  existential  with  the  environment  held  abstract.  Even  if  the 
code  is  handled  uniformly,  the  function  must  inspect  the  type  of  the  environment  (which  is  also  the 
witness  type  of  the  existential  package)  to  pickle  it.  This  shows  that  at  the  term  level,  the  analysis 
must  proceed  inside  a  quantified  type.  In  Section  3.3.1,  we  show  the  encoding  of  a  polymorphic 
equality  function  in  our  calculus;  the  comparison  of  existential  values  requires  a  similar  technique. 
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The  reason  for  not  restricting  the  quantified  type  variable  to  a  finite  set  of  kinds  is  twofold. 
Restricting  type  analysis  to  a  finite  number  of  kinds  would  be  ad  hoc  and  there  is  no  way  of 
satisfactorily  predetermining  this  finite  set  (this  is  even  more  the  case  when  we  compile  Java  into 
a  typed  intermediate  language  [LST99]).  More  importantly,  if  the  kind  of  the  bound  variable  is  a 
known  constant  in  the  corresponding  branch  of  the  Typerec  construct,  then  it  is  easy  to  generalize 
the  non-termination  example  of  the  previous  section  and  break  the  decidability  of  the  type  system. 

3.2.3  The  solution 

The  key  problem  in  analyzing  quantified  types  such  as  the  polymorphic  type  Vcr :  17.  a  — >  a  is  to 
determine  what  happens  when  the  iteration  reaches  the  quantified  type  variable  a,  or  (in  the  general 
case  of  type  variables  of  higher  kinds)  a  normal  form  which  is  an  application  with  a  type  variable 
in  the  head. 

One  approach  would  be  to  leave  the  type  variable  untouched  while  analyzing  the  body  of  the 
quantified  type.  The  equational  theory  of  the  type  language  then  includes  a  reduction  of  the  form 
(Typerec  a  of  . . .)  a  so  that  the  iterator  vanishes  when  it  reaches  a  type  variable.  However 
this  would  break  the  confluence  of  the  type  language — the  application  of  A  a :  Q.  Typerec  a  of . . . 
to  t  would  reduce  in  general  to  different  types  if  we  perform  the  /3-reduction  step  first  or  eliminate 
the  iterator  first. 

Crary  and  Weirich  [CW99]  propose  another  method  for  solving  this  problem.  Their  language 
LX  allows  the  representation  of  terms  with  bound  variables  using  deBruijn  notation  and  an  encod¬ 
ing  of  natural  numbers  as  types.  To  analyze  quantified  types,  the  iterator  carries  an  environment 
mapping  indices  to  types;  when  the  iterator  reaches  a  type  variable,  it  returns  the  corresponding 
type  from  the  environment.  This  method  has  several  disadvantages. 

•  It  is  not  fully  reflexive,  since  it  does  not  allow  analysis  of  all  quantified  types — their  analysis 
is  restricted  to  types  with  quantification  only  over  variables  of  kind  fi. 

•  The  technique  is  “limited  to  parametrically  polymorphic  functions,  and  cannot  account  for 
functions  that  perform  intensional  type  analysis”  [CW99,  Section  4.1].  For  example  poly¬ 
morphic  types  such  as  Vcr :  O.  Typerec  a  of  . . .  arc  not  analyzable  in  their  framework. 

•  The  correctness  of  the  structure  of  a  type  encoded  using  deBruijn  notation  cannot  be  verified 
by  the  kind  language  (indices  not  corresponding  to  bound  variables  go  undetected,  so  the 
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environment  must  provide  a  default  type  for  them),  which  does  not  break  the  type  soundness 
but  opens  the  door  for  programmer  mistakes. 

To  account  for  non-parametrically  polymorphic  functions,  we  must  analyze  the  quantified  type 
variable.  Moreover,  we  want  to  have  confluence  of  the  type  language,  so  /3-reduction  should  be 
transparent  to  the  iterator.  This  is  possible  only  if  the  analysis  gets  suspended  when  it  reaches  a 
type  variable  (or  an  application  with  a  type  variable  in  the  head),  and  resumes  when  the  variable 
gets  substituted.  Therefore,  we  consider  (Typerec  a  of  . . .)  to  be  a  normal  form.  For  example,  the 
result  of  analyzing  the  body  ( a  — >  int)  of  the  polymorphic  type  Vcr :  k.  a  — ►  int  is 

Typerec  (cr  ->  int)  of  (rint;  r_^;  rv)  a  int  (Typerec  a  of  (rint;  rv))  (rint) 

We  will  formalize  the  analysis  of  quantified  types  while  presenting  the  type  reduction  rules  of  the 
Typerec  construct  (Figure  3.6). 

The  other  problem  is  to  analyze  quantified  types  when  the  quantified  variable  can  be  of  an 
arbitrary  kind.  In  our  language  the  solution  is  similar  at  both  the  type  and  the  term  levels:  we  use 
kind  polymorphism!  We  introduce  kind  abstractions  at  the  type  level  (A j.  r)  and  at  the  term  level 
(A+j.  e)  to  bind  the  kind  of  the  quantified  variable.  (See  Section  3.3  for  details.) 

It  is  important  to  note  that  our  language  provides  no  facilities  for  kind  analysis.  Thus  every  type 
function  of  polymorphic  kind  is  parametrically  polymorphic.  Analyzing  the  kind  n  of  the  bound 
variable  a  in  the  type  V  (A a :  n.  r)  would  let  us  synthesize  a  type  of  the  same  kind,  for  every  kind 
k.  This  type  could  then  be  used  to  create  non-terminating  reduction  sequences  [HM99]. 

3.3  Analyzing  quantified  types 

In  the  impredicative  calculus,  the  polymorphic  types  Vcc :  k.  t  can  be  viewed  as  generated  by  an 
infinite  set  of  type  constructors  VK  of  kind  (k  — »  fl)  — *  fi,  one  for  each  kind  n.  The  type  Vet :  n.  r 
is  then  represented  as  VK  (Act :  k.  t).  The  kinds  of  constructors  that  can  generate  types  of  kind  O 


24 


(kinds) 

re 

::=  12 

1  re  -»•  re'  |  j  |  Vj. 

re 

(types) 

r 

::=  int 

1  1  VJ'  1 

— »  V  ¥ 

1  Q 

Aj.  t  |  A  a :  re.  t 

r  [re]  |  r  t' 

|  Typerec[re]  r  of  (rint; 

r-A  A/j  A/-) 

(values) 

V 

::=  *  | 

A+j.  e  Aa :  re.  e 

Xx\T.e  |  fix  x'.t.v 

(terms) 

e 

::=  v  | 

x  e  [re]+  e  [r] 

ee! 

1  typecase[r]  t  of  (cjnt,  c — 

Figure  32 

Z:  Syntax  of  the  Xf 

language 

Va: re.  t  =  (V  [re])  (A a: re.  r) 

V+j.  t  =  V+  (Aj.  r) 

Figure  3.3:  Syntactic  sugar  for  Xf  types 


then  would  be 


int  :  12 

vn  :  (n  ^  n)  ->  n 

VK  :  (re  — >  12)  — >  12 


We  can  avoid  the  infinite  number  of  VK  constructors  by  defining  a  single  constructor  V  of  polymor¬ 
phic  kind  Vj.  (j  — >■  12)  — >  12  and  then  instantiating  it  to  a  specific  kind  before  forming  polymorphic 
types.  More  importantly,  this  technique  also  removes  the  negative  occurrence  of  12  from  the  kind 
of  the  argument  of  the  constructor  Vq.  Hence  we  extend  Fu  with  polymorphic  kinds  and  add  a  type 
constant  V  of  kind  Vj.  ( j  — >  12)  — ►  12  to  the  type  language.  The  polymorphic  type  Vcr :  re.  r  is  now 
represented  as  V  [re]  (Aa :  re.  r). 

We  define  the  syntax  of  the  Xf  calculus  in  Figure  3.2,  and  some  derived  forms  of  types  in 
Figure  3.3.  The  static  semantics  of  Xf  is  shown  in  Figures  3.4,  3.5  and  3.6  as  a  set  of  rules  for 
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Kind  formation  £  F  k  I 


£Ffi 


j  €  £  £  F  k  £  F  k' 

£  F  j  £  F  k  — >  k' 


£,j  \~  k 
£  F  Vj.  k 


Type  environment  formation  £  F  A 

£F A 

£  F  e  £  F  A,  o::k 

Type  formation  £;  A  h  r  :  n 
£F  A 


£;Ah  int 
£;Ah  (—») 


fi  ->  n  -*■  n 


£  F  A  ct :  k  in  A 


£;  A  F  V  :  Vj.  (j  - 

■>  fi)  — >  fi 

_L 

<1 

£ ;  A  F  V+  :  (Vj.fi) 

fi 

£,  j;  A  F  r  :  k 

£;  A  F 

t  : 

Vj'.K 

£;  A  F  Aj.  r  :  Vj.  k  £;  A  F  t 

M  =  [«' 

£;A,q:kFt  :  k! 

£;  A  F  r 

:  «/ 

£;  A  F  A ot.k.t  :  k  — > 

£;  A  F  r  t' 

£;  A  F  t  : 

fi 

£;  A  F  Tint  : 

K 

£;  A  F  : 

fi  — >  fi  — >  k  — > 

k  — 

■>  ft 

£;AFrv  : 

Vj.  (j  — >  fA)  — > 

(j  ~ 

T  ft)  — .  ft 

£ ;  A  F  Tyf  : 

(Vj.fi) -.(Vj. 

«)  - 

*  ft 

£;  A  F  Typerec[«]  r  of  (rint;  r_^;  rv;  r^)  : 


Figure  3.4:  Type  formation  rules  of  Xf 


Term  environment  formation  £ ;  A  b  T 

£h  A 

£;  A  b  T 

£;  A  b  r  :  12 

£;Ahs 

<F;  A  b  T. 

,X\T 

Term  formation 

£;  A;  T  b  e  :  r 

£;  A;  T  b  e  :  r 

£;  A  b  r  r1  : 

:  n 

£;  A  b  T 

<5;  A;  The  :  r'  £;  A;  T  b  i  :  int 


£;  A  b  T  x:  r  in  T 
£;  A;  T  b  x  :  r 

£;  A,  a: At;  T  b  v  :  r 
£;  A;  r  b  Act : k.  v  :  \/a:n.T 


£,j;A;T  b  v  :  r 
<5;  A;  T  b  A+j.  v  :  V+j.  r 

<5;  A;  T,  x:t  b  e  :  t' 

£;  A;  T  b  Xx  :r.  e  :  r  — >  r7 


<5;  A;  T,  x  :r  b  v  :  r 

r  =  V  ji ...  jn.Wcxi Ki .. .  otm :  :ti  >  T2  ■ 
n  >  0,  m  >  0 

<5;  A;  T  b  fix  x  :t.  n  :  r 

£;  A;  T  b  e  :  V+r  £  b  k 
£]  A;  T  b  e  [k]+  :  r  [k] 

£]  A;  T  b  e  :  V  [«]  r  ^;Abr'  :  k 
£;  A;  T  b  e  [V]  :  r  t' 

f;A;rbe:r'^r  ^;A;rbe':r' 
<5;  A;  T  b  e  e7  :  r 

£;  A  b  r  :  12  — ■*  12 
£;A  b  r'  :  17 


<?;  A;  T  b  eint 

r  int 

£;  A;  T  b 

Vct:12.  Vc/  :12.  r  (cc  — >  a') 

<F;  A;T  b  ev 

V+j.  Va :  j  — >  12.  r  (V  [j]  a) 

£;  A;  T  b  e^t- 

Va:  (Vj.  12).  r  (V+a) 

£;  A;T  b  typecasefr]  r'  of  (ejnt;  e^;  ey;  e^)  :  rr' 


Figure  3.5:  Term  formation  rules  of  Xf 
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£;  A  b  Typerec[K]  int  of  (rin t;  r^;  rv;  r^)  rint  :  k 

£;  A  b  Typerec[K,]  n  of  (rint;  r^;  rv;  r^)  r(  :  k 

£;  A  b  Typerec[K,]  r2  of  (rjnt;  r_*;  rv;  r^)  t'2  :  k 


<5;  A  b  Typerec[K]  ((-*)  n  r2)  of  (rint;  t_^;  rv;  r^)  T_^  n  r2  r(  : 

£]A,a:n'  b  Typerec[«]  (ra)  of  (rint;  r_^;  ry;  r^f)  ^  t1  :  n 

£ ;  a  b  Typerec[K]  (V  [«']  r)  of  (rint;  r_^;  rv;  t^) 
rv  [«/]  r  (Aa:  k!  .  t')  :  k 

£,j;  A  b  Typerec[«]  (r  [j])  of  (Tint;  r_^;  rv;  r^)  ^  t'  :  k 
£\  A  b  Typerec[K]  (V+r)  of  (Tint;  r_^;  rv;  r^)  rvfr(Aj.  r')  :  k 


K 


Figure  3.6:  Xf  type  reduction  rules 


judgements  using  the  following  environments: 


kind  environment  £  ::=  e\  £,j 

type  environment  A  ::=  e  |  A ,a:n 

term  environment  T  ::=  e  |  F.x:t 

The  Typerec  operator  analyzes  polymorphic  types  with  bound  variables  of  arbitrary  kind.  The 

corresponding  branch  of  the  operator  must  bind  the  kind  of  the  quantified  type  variable;  for  that 
purpose  the  language  provides  kind  abstraction  (A j.  r)  and  kind  application  (r  [«])  at  the  type  level. 
The  formation  rules  for  these  constructs,  excerpted  from  Figure  3.4,  arc 

£,  j;  A  F  r  :  k  £;  A  hr:  Vj.  k  £  \~  k' 

£;AFA  j.r  :  Vj.  k  f ;  A  h  t  [k']  :  [n'/jjn 

Similarly,  while  analyzing  a  polymorphic  type,  the  term-level  construct  typecase  must  bind  the 
kind  of  the  quantified  type  variable.  Therefore,  we  introduce  kind  abstraction  (A +j.  e)  and  kind  ap¬ 
plication  (e  [k]  )  at  the  term  level.  To  type  the  term-level  kind  abstraction,  we  need  a  type  construct 
V+j.  r  that  binds  the  kind  variable  j  in  the  type  r.  The  formation  rules  arc  shown  below. 

£,  j;  A;  T  F  v  :  r  £;  A;  T  F  e  :  V+j.  r  £  F  k 

£;  A;  T  F  A +j.  v  :  V+j.  r  £;  A;  T  h  e  [k]+  :  [k/j]t 

However,  since  our  goal  is  fully  reflexive  type  analysis,  we  need  to  analyze  kind-polymorphic  types 
as  well.  As  with  polymorphic  types,  we  can  represent  the  type  V  .y.  r  as  the  application  of  a  type 
constructor  V+  of  kind  (Vj.  H)  — >  Q  to  a  kind  abstraction  A  j.  r.  Thus  the  kinds  of  the  constructors 
for  types  of  kind  O  arc 

int  : 

V  :  Vj.  (j  -r  Cl)  ->  n 
V+  :  (Vj.  ft)  -+  n 

None  of  these  consttuctors’  arguments  have  the  kind  ft  in  a  negative  position;  hence  the  kind  ft 
can  now  be  defined  inductively  in  terms  of  these  constructors.  The  Typerec  construct  is  then  the 
iterator  over  this  inductive  definition.  The  formation  rule  for  Typerec  follows  naturally  from  the 
type  reduction  rules  (Figure  3.6).  Depending  on  the  head  constructor  of  the  type  being  analyzed. 
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Typerec  chooses  one  of  the  branches.  At  the  int  type,  it  returns  the  Tjnt  branch.  At  the  function 
type  t  — >  t' ,  it  applies  the  r_^  branch  to  the  components  r  and  t'  and  to  the  result  of  the  iteration 
over  r  and  r' . 

When  analyzing  a  polymorphic  type,  the  reduction  rule  is 

Typerec[K]  (Vctk/.t)  of  (rint;  r_>;  rv;  tv f) 
t\/{k'](Xoc.k' .t)  (Xa :  k! .  Typerec[ft]  r  of  (rint;  t_»;  rv;  r^)) 

Thus  the  V-branch  of  Typerec  receives  as  arguments  the  kind  of  the  bound  variable,  the  abstraction 
representing  the  quantified  type,  and  a  type  function  encapsulating  the  result  of  the  iteration  on  the 
body  of  the  quantified  type.  Since  Ty  must  be  parametric  in  the  kind  k!  (there  are  no  facilities 
for  kind  analysis  in  the  language),  it  can  only  apply  its  second  and  third  arguments  to  locally 
introduced  type  variables  of  kind  n'.  We  believe  this  restriction,  which  is  crucial  for  preserving 
strong  normalization  of  the  type  language,  is  quite  reasonable  in  practice.  For  instance  ry  can  yield 
a  quantified  type  based  on  the  result  of  the  iteration. 

The  reduction  rule  for  analyzing  a  kind-polymorphic  type  is 

Typerec[K]  (V+y.r)  of  (rint;  r_^;  rv;  r/) 
v  (A>  T)  (Ai-  Typerec[fi]  r  of  (rint;  r_^;  rv;  r^)) 

The  arguments  of  the  r,r  arc  the  kind  abstraction  underlying  the  kind-polymorphic  type  and  a  kind 
abstraction  encapsulating  the  result  of  the  iteration  on  the  body  of  the  quantified  type. 

At  the  term  level  type  analysis  is  carried  out  by  the  typecase  construct;  however,  it  is  not 
iterative  since  the  term  language  has  a  recursion  primitive,  fix.  The  ey  branch  of  typecase  binds 
the  kind  and  the  type  abstraction  carried  by  the  type  constructor  V,  while  the  e...  branch  binds  the 
kind  abstraction  carried  by  V+. 

typecase[r]  (V  [k]  t')  of  (eint;  e^;  ev;  e^y)  ey  [k]+  [t’} 
typecase[r]  (VV)  of  (eint;  e^;  ev;  e^)  e^  [r'] 

The  operational  semantics  of  the  term  language  of  A  f  is  presented  in  Figure  3.7. 

The  language  Af  has  the  following  important  properties.  The  proofs  arc  given  in  Appendix  A. 

Theorem  3.3.1  Reduction  of  well-formed  types  is  strongly  normalizing. 
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(Ax : r.  e)  v \v/x\ e  (fi Xx:t.v)v' ^  ([fix  x:t.v/x]v)  v' 

(A a:  ac.  x)[t]  [r/a]x  (fix x: r.  x)[r]  ([fix  x:  r.  x/x]x)[r] 

(A+j.x)[k]+  \k/ j\v  (fix  x'.t.v) [k]+~>  ([fix  x : r.  x/x]x) [k]+ 

e  e!  e  d  e!  e' 

eei^e'ei  ve^ve'  e[r]  ^  e'fr]  e[«;]+ c'[k]+ 

typecase[r]  int  of  (ejnt;  e^;  ey;  e^)  eint 

typecase[r]  (n  —  r2)  of  (eint;  e^;  ev;  e^)  [ri]  [r2] 
typecase[r]  (V  [k]  t)  of  (eint;  e^;  ev;  e^)  ev  [k]+  [r] 
typecase[r]  (V+r)  of  (eint;  e^;  ev;  e^f)  ^  e ^  [r] 

s:  £  F  t'  v' :  O  7/  is  a  normal  form 

typecase[r]  r'  of  (ejnt;  e^;  ev;  e^) 
typecase[r]  z/  of  (eint;  e^;  ey;  e^r) 

Figure  3.7:  Operational  semantics  of  Xf 


Theorem  3.3.2  Reduction  of  well-formed  types  is  confluent. 

Theorem  3.3.3  If  £ ;  e;  c  F  e :  r  then  either  e  is  a  value  or  there  exists  an  e'  such  that  e  e' . 

3.3.1  Example:  Polymorphic  equality 

For  ease  of  presentation,  we  will  use  ML-style  pattern  matching  syntax  to  define  a  type  involving 
Typerec.  Instead  of 


r  =  Aa:fITyperec[K,]  a  of  (rint;  r^;  ry;  r^r) 
where  r_^  =  A«i :  fl.  A a2  :  fl.  Aay :  n.  \a'2  :  n.  t'_ 
ry  =  A j.  Xa:j  — >  0.  \a!  :j  —>  k.  t y 

=  Aa :  (Vj.  0).  Aa' :  (Vj.  k). 
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We  will  write 


t  (int) 

—  rint 

r  (ai  — >  a2) 

=  [r(ai),r  (a2)/aj,a'2 

r  (V  \j]  ai) 

=  [Aa:  j.  r  (ai  a)/a/]ry 

r  (V+ai) 

=  [Aj.r(ai  bD/a']^ 

To  illustrate  the  type-level  analysis  we  will  use  the  Typerec  operator  to  define  the  class  of  types 
admitting  equality  comparisons  [HM95].  To  make  the  example  non-trivial  we  extend  the  language 
with  a  product  type  constructor  x  of  the  same  kind  as  — »,  and  with  existential  types  with  type 
constructor  3  of  kind  identical  to  that  of  V.  We  will  write  3a:  k.t  for  3  [/,:.]  (Aa  :  n.  r).  Corre¬ 
spondingly  we  extend  Typerec  with  a  product  branch  rx  and  an  existential  branch  rg  which  behave 
in  exactly  the  same  way  as  the  r_.  branch  and  the  t\j  branch  respectively.  We  will  use  Bool  instead 
of  int. 

A  polymorphic  function  eq  comparing  two  objects  for  equality  is  not  defined  on  values  of 
function  or  polymorphic  types.  We  will  enforce  this  restriction  statically  by  defining  a  type  operator 
Eq  of  kind  17  — »  17,  which  maps  function  and  polymorphic  types  to  the  type  Void  =  Va :  17.  a  (a 
type  with  no  values),  and  require  the  arguments  of  eq  to  be  of  type  Eq  r  for  some  type  r.  Thus, 
given  any  type  r,  the  function  Eq  serves  to  verify  that  a  non-equality  type  does  not  occur  inside  r. 

Eq  (Bool)  =  Bool 

Eq  («i  — >  a2)  =  Void 

Eq(aixa2)  =  Eq  (an)  x  Eq  (a2) 

Eq  (V  [j]  a)  =  Void 

Eq  (V+  a)  =  Void 

Eq  (3  [j]  a)  =3  [j]  (Aai :  j.  Eq  (a  an)) 

The  property  is  enforced  even  on  hidden  types  in  an  existentially  typed  package  by  the  reduction 
rule  for  Typerec  which  suspends  its  action  on  normal  forms  with  a  type  variable  at  the  head.  For 
instance  a  term  e  can  only  be  given  a  type  Eq  (3a :  17.  a  x  a)  =  3a  :  17.  Eq  a  x  Eq  a  if  it  can  be 
shown  that  e  is  a  pair  of  terms  of  type  Eq  r  for  some  r,  i.e.,  terms  of  equality  type. 

The  term-level  analysis  of  quantified  types  is  illustrated  by  the  polymorphic  equality  function. 
The  term  constructs  for  introduction  and  elimination  of  existential  types  have  the  usual  formation 
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letrec 

heq:Va:fI  Vc/:fl  Eqa  — +  Eq  a'  — +  Bool 

=  Aar.Q.  Aa'  :£t. 

typecase[A7 :  fl  Eq  7  — ►  Eq  a'  — >  Bool]  a  of 
Bool  =>  Ax :  Bool. 

typecase[A7:0.  Eq7  — ►  Bool]  a1  of 
Bool  =7-  Ay: Bool. primEqBooIxy 
=>  ...  false 

Pi  x  p2  =>  Ax :  Eq  /3i  x  Eq  p2. 

typecase[A7:f7.  Eq7  — ►  Bool]  a'  of 

P'lXfiz  =>  Ay: Eq  p[  x  EqP'2. 

heq  [/?i]  [/3'](7r1(x))(7T1(y))and 
heq  \(32]  [P'2\  (tt2(x))  (7r2(y)) 

=>  ...  false 

3[j]/3  =7-  Xx:(3f31:j.  Eq  (PPi)). 

typecase[A7:fl  Eq7  — ►  Bool]  a'  of 

3  [/]/?'  ^  Ay :  (3#  :j'.Eq  (/?#)). 

open  x  as  (Pi  :j.  xc:  Eq  (P  Pi))  in 
open  y  as  (P[:f,  yc:Eq  (P' P[))  in 
heq  \ppp  \p’  P(]  xcyc 
=>  ...  false 

in  let  eq  =  Aa :  fl  Ax :  Eq  a.  Ay :  Eq  a.  heq  [a]  [a]  x  y 

in  . . . 


Figure  3.8:  Polymorphic  equality  in  Xf 


rules: 


£;  A;  T  F  e  :  3  [k]  t  £;A  hr7  :  fl 
■  (A  (x.k.t)t  £]  A,  a:  k]T  ,  x:t  a  F  e/  :  t' 

£;  A;  T  F  (a:  n  =  t',  e:  t)  :  Bcc.k.t  £\  A;  T  F  open  eas  {«:«,  s:ra)  in  e'  :  r' 

The  polymorphic  equality  function  eq  is  defined  in  Figure  3.8  (the  letrec  construct  can  be  derived 
from  the  fix).  The  domain  type  of  the  function  is  restricted  to  types  of  the  form  Eq  r  to  ensure  that 
only  values  of  types  admitting  equality  arc  compared. 

Consider  the  two  packages  v  =  (a  :  =  Bool,  false  :  a)  and  v'  =  (a  :  =  Bool  x 

Bool,  (true,  true) :  a).  Both  are  of  type  3a :  U.  a,  which  makes  the  invocation  eq  \3a  :£l.a]v  v1 
legal.  But  when  the  packages  arc  open,  the  types  of  the  packaged  values  may  (as  in  this  example) 
turn  out  to  be  different.  Therefore  we  need  the  auxiliary  function  heq  to  compare  values  of  possibly 


33 


different  types  by  comparing  their  types  first.  The  function  corresponds  to  a  matrix  on  the  types  of 
the  two  arguments,  where  the  diagonal  elements  compare  recursively  the  constituent  values,  while 
off-diagonal  elements  return  false  and  are  abbreviated  in  the  figure. 

The  only  interesting  case  is  that  of  values  of  an  existential  type.  Opening  the  packages  provides 
access  to  the  witness  types  3i  and  3\  of  the  arguments  x  and  y.  As  shown  in  the  typing  rules,  the 
actual  types  of  the  packaged  values,  X  and  y,  are  obtained  by  applying  the  corresponding  type 
functions  /3  and  3'  to  the  respective  witness  types.  This  yields  a  perhaps  unexpected  semantics  of 
equality.  Consider  this  invocation  of  the  eq  function  which  evaluates  to  true: 

eq  [3a:3i.  a] 

(a:3l  =  33:31. 3,  (3'-3l  =  Bool,  true :  Eq  3) :  Eq  a) 

(a :  O  =  33 : 31  — ►  fk 3  Bool,  (/3 :  fi  — >  fi  =  A7 :  fk  7,  true :  Eq  (/3  Bool)} :  Eq  a) 

At  runtime,  after  the  two  packages  arc  opened,  the  call  to  heq  is 

heq  [33 :  31.  3}  [33 :  31  ->  31.  3  Bool] 

(3:31  =  Bool,  true : Eq /?) 

(3 : 31  — ►  31  =  A7 : 31. 7,  true :  Eq  (3  Bool)) 

This  term  evaluates  to  true  even  though  the  type  arguments  arc  different.  The  reason  is  that  what 
is  being  compared  arc  the  actual  types  of  the  values  before  hiding  their  witness  types.  Tracing  the 
reduction  of  this  term  to  the  recursive  call  heq  \3  3i\  W  ft'\  \  xc  Yc  we  fi  nd  out  it  is  instantiated  to 

heq  [(A/3 : 17.  3)  Bool]  [(A/3 :  17  — >  17.  /3  Bool)  (A7 : 17. 7)]  true  true 

which  reduces  to  heq  [Bool]  [Bool]  true  true  and  thus  to  true. 

This  result  is  justified  since  the  above  two  packages  of  type  3a  :  31.  a  will  indeed  behave 
identically  in  all  contexts.  An  informal  argument  in  support  of  this  claim  is  that  the  most  any 
context  could  do  with  such  a  package  is  open  it  and  inspect  the  type  of  its  value  using  typecase, 
but  this  will  only  provide  access  to  a  type  function  r  representing  the  inner  existential  type.  Since 
the  kind  k  of  the  domain  of  r  is  unknown  statically,  the  only  non-trivial  operation  on  r  is  its 
application  to  the  witness  type  of  the  package,  which  is  the  only  available  type  of  kind  n.  As  we 
saw  above,  this  operation  will  produce  the  same  result  (namely  Bool)  in  both  cases.  Thus,  since  the 
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two  arguments  to  eq  arc  indistinguishable  by  Xf  contexts,  the  above  result  is  perfectly  sensible. 


3.3.2  Discussion 

Before  moving  on,  it  would  be  worthwhile  to  analyze  the  Xf  language.  Specifically,  what  is  the 
price  in  terms  of  complexity  of  the  type  theory  that  can  be  attributed  to  the  requirements  that  were 
imposed? 

In  Section  3.2.2  we  saw  that  an  iterative  type  operator  is  essential  to  typechecking  many  type- 
directed  operations.  Even  when  restricted  to  compiling  ML  we  still  have  to  consider  analysis  of 
polymorphic  types  of  the  form  Va :  fi.  r,  and  their  ad  hoc  inclusion  in  kind  Q  makes  the  latter  non- 
inductive.  Therefore,  even  for  this  simple  case,  we  need  kind  polymorphism  in  an  essential  way  to 
handle  the  negative  occurrence  of  1?  in  the  domain  of  V.  In  turn,  kind  polymorphism  allows  us  to 
analyze  at  the  type  level  types  quantified  over  any  kind;  hence  the  extra  expressiveness  comes  for 
free.  Moreover,  adding  kind  polymorphism  does  not  entail  any  heavy  type-theoretic  machinery — 
the  kind  and  type  language  of  Xf  is  a  minor  extension  (with  primitive  recursion)  of  the  well-studied 
calculus  F2\  we  use  the  basic  techniques  developed  for  F2  [GLT89]  to  prove  properties  of  our  type 
language. 

The  kind  polymorphism  of  Xf  is  parametric,  i.e.,  kind  analysis  is  not  possible.  This  property 
prevents  in  particular'  the  construction  of  non-terminating  types  based  on  variants  of  Girard’s  J 
operator  using  a  kind-comparing  operator  [HM99]. 

For  analysis  of  quantified  types  at  the  term  level  we  have  the  new  construct  A +j.  e.  This  does  not 
result  in  any  additional  complexity  at  the  type  level — although  we  introduce  a  new  type  constructor 
Vt  the  kind  of  this  construct  is  defined  completely  by  the  original  kind  calculus,  and  the  kind 
and  type  calculus  is  still  essentially  F2.  The  term  calculus  becomes  an  extension  of  Girard’s  XU 
calculus  [Gir72],  hence  it  is  not  normalizing;  however  it  already  includes  the  general  recursion 
construct  fix,  necessary  in  a  realistic  programming  language. 

Restricting  the  type  analysis  at  the  term  level  to  a  finite  set  of  kinds  would  help  avoid  the 
term-level  kind  abstraction.  However,  even  in  this  case,  we  would  still  need  kind  abstraction  to 
implement  a  type  erasure  semantics.  On  the  other  hand,  having  kind  abstraction  at  the  term  level 
of  Xf  adds  no  complications  to  the  transition  to  type  erasure  semantics. 


35 


{kinds) 

K 

:= 

;> 

■s-* 

"se 

T 

i- 

G 

(types) 

T 

int  |  -»  |  V  |  V+  |  R 

l 

rn  1  rj~]  1  rj~i  I  rri  1  rj~ i 

T  int  |  -*— ►  |  V  |  \  r 

l 

a  |  A  j.  t  t[k\  Xcc.k.t  tt' 

1 

Tagrec[K]  r  of  (rint;  r_^;  rv;  r^;  tr) 

( values ) 

V 

:= 

i  A  j.  v  \  Aa  :k.v  \  A x:r.e  f  ix  x :  r.  v 

1 

Rint  1  I  [r]  I  R^  [r]  v 

1 

R_»  [r]  v  [t']  |  R^  [r]  v  [t'\  v' 

1 

Rv  |  Rv  [«]+  |  Rv  [k}+  [t]  |  Rv  [k}+  [t]  [t'] 

1 

RvM+[r][r> 

1 

FV  [T1  [t]  v 

1 

Ri?  1  rhH  1  RSH« 

(terms) 

e 

;  = 

v  |  x  |  e  [k]+  \  e[r\  \  ee' 

1 
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Figure  3.9:  Syntax  of  the  Xf,  language 

3.4  Type  erasure  semantics 

The  main  motivation  for  developing  type  systems  for  runtime  type  analysis  is  to  use  them  in  a  type- 
based  certifying  compiler.  Crary  et  al.  [CWM98]  proposed  a  framework  that  helps  in  propagating 
types  through  a  type-preserving  compiler.  From  an  implementor’s  point  of  view,  this  framework 
(hereafter  referred  to  as  the  CWM  framework)  seems  to  simplify  some  phases  in  a  type  preserving 
compiler;  most  notably,  typed  closure  conversion  [MMH96].  The  main  idea  is  to  construct  and 
pass  terms  representing  types,  instead  of  the  types  themselves,  at  runtime.  This  allows  the  use  of 
pre-existing  term  operations  to  deal  with  runtime  type  information.  Semantically,  singleton  types 
arc  used  to  connect  a  type  to  its  representation. 

However,  the  framework  proposed  in  [CWM98]  supports  the  analysis  of  inductively  defined 
types  only;  it  does  not  support  the  analysis  of  quantified  types.  In  this  section,  we  show  how 
A f  can  be  translated  into  a  type-erasure  language.  We  call  this  language  A')).  Figure  3.9  shows  the 
syntax  of  the  Xf,  language.  To  make  the  presentation  simpler,  we  will  describe  many  of  the  features 
in  the  context  of  the  translation  from  Xf. 
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3.4.1  The  analyzable  components  in  Xf, 

In  the  type  calculus  is  split  into  types  and  tags:  While  types  classify  terms,  tags  arc  used  for 
analysis.  We  extend  the  kind  calculus  to  distinguish  between  the  two.  The  kind  includes  the 
set  of  types,  while  the  kind  T  includes  the  set  of  tags.  For  every  constructor  that  generates  a  type 
of  kind  Q,  we  have  a  corresponding  constructor  that  generates  a  tag  of  kind  T;  for  example,  int 
corresponds  to  Tjnt  and  — *  corresponds  to  T_^.  The  type  analysis  construct  at  the  type  level  is 
Tagrec  and  operates  only  on  tags. 

At  the  term  level,  we  add  representations  for  tags.  The  term  level  operator  (now  called  repcase) 
analyzes  these  representations.  All  the  primitive  tags  have  corresponding  term  level  representa¬ 
tions;  for  example,  Tjnt  is  represented  by  Rjnt.  Given  any  tag,  the  corresponding  term  representa¬ 
tion  can  be  constructed  inductively. 

3.4.2  Typing  term  representations 

The  type  calculus  in  \y,  includes  a  unary  type  constructor  It  of  kind  T  — ►  fi  to  type  the  term 
level  representations.  Given  a  tag  r  (of  kind  T),  the  term  representation  of  r  has  the  type  Rt. 
For  example,  Rjnt  has  the  type  RT\nt.  Semantically,  It  r  is  interpreted  as  a  singleton  type  that  is 
inhabited  only  by  the  term  representation  of  r  [CWM98], 

If  the  tag  r  is  of  a  function  kind  k  — >  then  the  term  representation  of  r  is  a  polymorphic 

function  from  representations  to  representations: 

R^k'  (t)  =  V/3 :  k.  Rk  (P)  RK'  (t  f3) 

However  a  problem  arises  if  r  is  of  a  variable  kind  j.  The  only  way  of  knowing  the  type  of  its 
representation  Rj  is  to  construct  it  when  j  is  instantiated.  Hence  programs  translated  into  A^>  must 
be  such  that  for  every  kind  variable  j  in  the  program,  a  corresponding  type  variable  aj ,  representing 
the  type  of  the  term  representation  for  a  tag  of  kind  j,  is  also  available. 

This  is  why  we  need  to  go  beyond  the  CWM  framework.  Their  source  language  does  not  in¬ 
clude  kind  polymorphism;  therefore,  they  can  compute  the  type  of  all  the  representations  statically. 
This  is  also  the  reason  that  we  need  to  introduce  a  new  set  of  primitive  type  constructors  and  split 
the  type  calculus  into  types  and  tags.  Consider  the  V  and  the  V+type  constructors  in  A".  The  V 
constructor  binds  a  kind  k.  When  it  is  translated  into  A^>.  the  translated  constructor  must  also,  in 
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|17|  =  T  | re  — ►  n'\  =  |re|  — >  |re'| 

|j|  =  j  |Vj.  re|  =  Vj.  (j  -»•  17)  -»•  |re| 

Figure  3.10:  Translation  of  A  j  kinds  to  kinds 


addition,  bind  a  type  of  kind  re  — >  17.  Therefore,  we  need  a  new  constructor  71/.  Similarly,  the 
V+  constructor  binds  a  type  function  of  kind  Vj.  17.  When  it  is  translated  into  Xf,  the  translated 
constructor  must  bind  a  type  function  of  kind  |Vj.  17|.  (See  Figure  3.10.)  Therefore,  we  introduce 
a  new  constructor  T Furthermore,  if  we  only  have  17  as  the  primitive  kind,  it  will  no  longer  be 
inductive.  (The  inductive  definition  would  break  for  Tv r).  Therefore,  we  introduce  a  new  kind  T 
(for  tags),  and  allow  analysis  only  over  tags. 

This  leads  us  to  the  kind  translation  from  Xf  to  Xf,  (Figure  3.10).  Since  the  analyzable  compo¬ 
nent  of  A^  is  of  kind  T,  the  Xf  kind  17  is  mapped  to  T.  The  polymorphic  kind  Vj.  re  is  translated  to 
Vj.  (j  — >  17)  — >  |re|.  Note  that  every  kind  variable  j  must  now  have  a  corresponding  type  variable 
ay.  Given  a  tag  of  variable  kind  j,  the  type  of  its  term  representation  is  given  by  ay- .  Since  the  type 
of  a  term  is  always  of  kind  17,  the  variable  ay  has  the  kind  j  — ►  17. 

Lemma  3.4.1  |[re'/j]re|  =  [|re'|/j]|re| 

Proof  By  induction  over  the  structure  of  re.  □ 

Figure  3.11  shows  the  function  RK.  Suppose  r  is  a  Xf  type  of  kind  re  and  |r|  is  its  translation 
into  Xf.  The  function  RK  gives  the  type  of  the  term  representation  of  |r|.  Since  this  function  is 
used  by  the  translation  from  Xf  to  Xf,  it  is  defined  by  induction  on  Xf  kinds. 

Lemma  3.4.2  [|re'| ,  RK> /j' ,ay](RK)  =  R^/j^ 

Proof  By  induction  over  the  structure  of  re.  □ 

The  formation  rules  for  tags  arc  displayed  in  Figure  3.12.  Since  the  translation  maps  X  f  type 
constructors  to  these  tags,  a  type  constructor  of  kind  re  is  mapped  to  a  corresponding  tag  of  kind 
|re|.  Thus,  while  the  V  type  constructor  has  the  kind  Xf.  ( j  — r  17)  — r  17,  the  Ty  tag  has  the  kind 

Vj.  (j  ->  fi)  -»•  (j  — >  T)  — r  T. 

Figure  3.13  also  shows  the  type  of  the  term  representation  of  the  primitive  type  construc¬ 
tors.  These  types  agree  with  the  definition  of  the  function  for  example,  the  type  of  R  ,  is 
Ro^o^o  (T_,).  The  term  formation  rules  in  Figure  3.13  use  a  tag  interpretation  function  F  that  is 
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£  b  A  £\  A  b  Oij  :  j  — >  fl 

£ ;  A  b  Rq  =  R  :  T  — >17  <F ;  A  b  R,j  =  a.j  :  j  — >  fl 

<5;  A  b  i?K  =  r  :  |k|  — r  £l  £;  A  b  i?K/  =  r'  :  |k'|  — >  14 
<5;  A  b  Rk^k'  =  Aa : \k  — +  «/|.  V/3 :  |k|.  r  /3  — ►  t'  (a/3)  :  |«  — >  k/|  — >  14 

<5,  j;  A,  cty  :j  — ►  14  b  RK  =  r  :  |k|  — >  14 
£;  A  b  =  Aa:|Vj.  k|.  V+j\  Vay  -*■  14.  r  (a  [j]  ay)  :  |Vj.  «| ->  14 

Figure  3.11:  Types  of  representations  at  higher  kinds 


explained  in  Section  3.4.4. 

3.4.3  Tag  analysis  in 

We  now  consider  the  tag  analysis  constructs  in  more  detail.  The  term  level  analysis  is  done  by 
the  repcase  construct.  Figure  3.13  and  Figure  3.14  show  its  static  and  dynamic  semantics  respec¬ 
tively.  The  expression  being  analyzed  must  be  of  type  Rt\  therefore,  repcase  always  analyzes 
term  representation  of  tags.  Operationally,  it  examines  the  representation  at  the  head,  selects  the 
corresponding  branch,  and  passes  the  components  of  the  representation  to  the  selected  branch. 
Thus  the  rule  for  analyzing  the  representation  of  a  polymorphic  type  is 

repcase[r]  Rv  [k]+[tk]  [r]  (e)  of  (eint;  e^;  ev;  e^;  eR ;  eM;  epi)  ev  [k]+[tk]  [r]  (e) 

Type  level  analysis  is  performed  by  the  Tagrec  construct.  The  language  must  be  fully  reflexive,  so 
Tagrec  includes  an  additional  branch  for  the  new  type  constructor  TR. 

Figure  3.15  shows  the  reduction  rules  for  the  Tagrec,  which  arc  similar  to  the  reduction  rules 
for  the  source  language  Typerec:  given  a  tag,  it  calls  itself  recursively  on  the  components  of  the 
tag  and  then  passes  the  result  of  the  recursive  calls,  along  with  the  original  components,  to  the 
corresponding  branch.  Thus  the  reduction  rule  for  the  function  tag  is 

Tagrec[/c]  ( TAtt ')  of  (rint;  r_^;  rv;  r^;  tr)  ^ 

t^tt'  (Tagrec[fi]  r  of  (rint;  r_^;  rv;  r^;  tr))  (Tagrec[/c]  t'  of  (rint;  r_^;  rv;  r^;  tr)) 
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Figure  3.12:  Formation  rules  for  the  new  type  constructs  in  A  ^ 


Term  formation  £;  A;  The  :  r 
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£;  A;T  P  repcase[r]  e  of  (ejnt;  e^;  ey;  e^r;  e#)  :  rr' 


Figure  3.13:  Formation  rules  for  the  new  term  constructs  in  A^ 


Similarly,  the  reduction  for  the  polymorphic  tag  is 


Tagrec[/c]  (Tv  [k]  tk  t)  of  (rint;  r_^;  rv;  t^;  rfl) 
TV[K]rKr(AQ::K.Tagrec[K]  (ra)  Of  (rint;  r^;  rv;  r^;  tJ) 


3.4.4  The  tag  interpretation  function 

Programs  in  Xf{  pass  tags  at  runtime  since  only  tags  can  be  analyzed.  However,  abstractions  and  the 
fixpoint  operator  must  still  carry  type  information  for  type  checking.  Therefore,  these  annotations 
must  use  a  function  mapping  tags  to  types.  Since  these  annotations  arc  always  of  kind  Q.  this 
function  must  map  tags  of  kind  T  to  types  of  kind  Q.  This  implies  that  we  can  use  an  iterator  over 
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(A x'.T.e)  v  [v/x\e 

(fix  x :  r.  v)  v'  ^  ([fi Xx:t.v/x\v)  v' 

(A ot.k.v)  [r]  [r/a\v 

(fix  x:  t.  v)  [r]  ([fix  x:  t.  v/x\v)  [r] 

(A +j.v)  M+-^>  [n/j]v 

(fi Xx-.T.v)  [/cf1-  ([fi Xx:t.v/x\v)  [k]+ 

e  ^  ei  e  ei 

ee'  ^  e\e'  v  e  ^  v  e\ 

e\  e  e\ 

e  [r]  ^  e\  [r]  e  [k]+  e\  [k]+ 

r6pcase[r]  R j nt  of  (cinti  c— >>  &r)  'n">  eint 

repcase[r]  [r']  (e')  of  (eint;  e^;  ev;  e^;  eR)  [r']  (e') 

repcase[r]  [r']  (e')  of  (eint;  e^;  ev;  e^;  eR)  [r']  (e') 

repcase[r]  R^  [n]  (ei)  [r2]  (e2)  of  (eint;  e^;  ev;  e^;  eR]  e M;  epi )  [ri]  (ei)  [r2]  (e2) 
repcase[r]  Rv  [k]+[tk]  [t']  (e')  of  (eint;  e^;  ev;  e^;  e#;  eM;  epZ)  ev  [k]+[tk]  [t']  (e') 

e  ^  e' 

repcase[r]  e  Of  (eint;  e^;  ev;  e^;  eR)  repcase[r]  e!  of  (eint;  e^;  ev;  e^;  eR) 

Figure  3.14:  Term  reduction  rules  of  X'f., 
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A  b  T3QT6C[k]  Tint  Of  (Tjnt,  T_>,  Ty,  TyT,  Tjf)  .  K 

£]A\-  Tagrec[K]  Tint  of  (rint;  r_^;  rv;  r^;  rK)  rint  :  k 

<5;  A  h  Tagrec[K]  ri  of  (rint;  r^;  rv;  r^;  rj  r(  :  k 

£;A\-  Tagrec[K]  r2  of  (rint;  r_^;  rv;  r^;  rj  ^  t'2  :  k 

£;  A  I-  Tagrec[/i]  (T_+  Ti  r2)  of  (rjnt;  r_^;  rv;  t^;  rH)  r—  n  r2  r(  r2  :  k 

<?;  a b  Tagrec[/i]  (r2a)  of  (rint;  r_>;  rv;  r^;  rH)  ^  r'  :  k 
£;  A  b  Tagrec[K]  (Tv  [«/]  Ti  r2)  of  (rint;  r^;  rv;  r^;  tJ  rv  [«/]  n  r2  (Aa:*/.  t')  :  k 

£,j;  A,  ay  :j  ->  f2  b  Tagrec[/i]  (r  [j]  ay)  Of  (Tint;  r-,.;  rv;  t^;  th)  t'  :  k 
£;  A  b  Tagrec[«]  (T^  r)  of  (Tint;  r_^;  rv;  t/ ;  tr)  r  (Aj.  Aay  :  j  ->  fi.  r')  :  k 

<5;  A  b  Tagrec[/i]  r  of  (Tint;  r_^;  rv;  t/;  th)  ^  t'  :  k 
£;  a  b  Tagrec[/i]  (T/tr)  of  (Tint;  r_^;  rv;  r^;  tr)  trtt'  :  k 


Figure  3.15:  Reduction  rules  for  Ay;,  Typerec 


tags  to  define  the  function  as  follows  (using  the  pattern  matching  syntax  as  before): 

F  (Tnt)  =  int 

F(T_>aia2)  =  F(ai)— >  F  (a2) 

F  (Tv  [j]  aj  a)  =  V/3 :  j.  aj  (5  ->  F  (a  (3) 

F  (T^r  a)  =  Vj.Vaj  :j  — >  ST  F  (a  [j]  ay) 

F  (Tr  a)  =  int 

The  function  F  takes  a  type  tree  in  the  T  kind  space  and  converts  it  into  the  corresponding  tree  in 
the  O  kind  space.  Therefore,  it  converts  the  tag  Tmt  to  the  type  int.  For  the  other  tags,  it  recursively 
converts  the  components  into  the  corresponding  types.  The  branch  for  the  TR  tag  is  bogus  but  of 
the  correct  kind.  The  language  Ay,  is  only  intended  as  a  target  for  translation  from  Xf — the  only 
interesting  programs  in  Xf,  are  the  ones  translated  from  Xf:  therefore,  the  TR  branch  of  F  will 
remain  unused. 

The  type  interpretation  function  has  the  following  properties. 

Lemma  3.4.3  [r'/a](F  (r))  =  F  ([r'/ajr) 

Proof  Follows  from  the  fact  that  none  of  the  branches  of  F  has  free  type  variables.  □ 
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Lemma  3.4.4  [re/j]( F  (r))  =  F  ([n/j\r) 

Proof  Follows  from  the  fact  that  none  of  the  branches  of  F  has  free  kind  variables.  □ 

The  language  Xf  has  the  following  properties.  The  proofs  arc  the  same  as  the  proofs  for  the 
corresponding  properties  of  A f  which  arc  shown  in  Appendix  A. 

Proposition  3.4.5  (Type  Reduction)  Reduction  of  well  formed  types  is  strongly  normalizing  and 
confluent. 

Proposition  3.4.6  (Type  Safety)  If  h  e  :  r,  then  either  e  is  a  value,  or  there  exists  a  term  e'  such 
that  e  ^  c!  and  F  e'  :t. 

3.5  Translation  from  Xf  to  A1^ 

In  this  section,  we  show  a  translation  from  Xf  to  A)).  The  languages  differ  mainly  in  two  ways. 
First,  the  type  calculus  in  Xf  is  split  into  tags  and  types,  with  types  used  solely  for  type  checking 
and  tags  used  for  analysis.  Therefore,  type  passing  in  Xf  will  get  converted  into  tag  passing  in 
Xf.  Second,  the  typecase  operator  in  Xf  must  be  converted  into  a  repcase  operating  on  term 
representation  of  tags. 

Figure  3.16  shows  the  translation  of  Xf  types  into  A))  tags.  The  primitive  type  constructors  get 
translated  into  the  corresponding  tag  constructors.  The  Typerec  gets  converted  into  a  Tagrec.  The 
translation  inserts  an  arbitrarily  chosen  well-kinded  result  into  the  branch  for  the  Tlt  tag  since  the 
source  contains  no  such  branch. 

The  term  translation  is  shown  in  Figure  3.17.  The  translation  must  maintain  two  invariants. 
First,  for  every  accessible  kind  variable  j,  it  adds  a  corresponding  type  variable  ay  this  variable 
gives  the  type  of  the  term  representation  for  a  tag  of  kind  j.  At  every  kind  application,  the  trans¬ 
lation  uses  the  function  RK  (Figure  3.11)  to  compute  this  type.  Thus,  the  translations  of  kind 
abstractions  and  kind  applications  arc 

\A+j.v\  =  A+j.Aaj:j  ->  Q.  |n|  \e[n]+\  =  |e|  [|k|]+[7?k] 

Second,  for  every  accessible  type  variable  a,  a  term  variable  xa  is  introduced,  providing  the  cor¬ 
responding  term  representation  of  a.  At  every  type  application,  the  translation  uses  the  function 
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l«l  = 

=  a 

|int| 

=  T\nt 

|Aj.t|  =  Aj.  A ctj-.j 

H 

=  T_+ 

\T Ml  =  r  [MR* 

|V| 

=  Tv 

Ackk.  r  =  Act:  |/c|.  r| 

ivl 

=v 

t  t'\  =  r  \t'\ 

|Typerec[K]  r  of  (rint;  t^;  rv;  t^)\  = 

Tagrec[|«|]  |r|  of  (|rint|;  |t-|;  |rv|;  jr^l;  A_:T.  A_:  |k|.  |rint|) 


Figure  3.16:  Translation  of  A f  types  to  A^>  tags 


|typecase[r]  t'  of  (eint;  e^;  ev;  e^f)! 

=  repcase[Aa:T.  F  (|r|  a)]  K(r')  of 

Rint  ^  | ^int 

|e_>| 

Rv  =Hev| 

R\A  le\Fl 

Rfl  =V  A/3:T.  A x:R /5. fix  x :  F  (|r|  (TR  /3)).x 


Figure  3.17:  Translation  of  Xf  terms  to  A^,  terms 


9fc(int)  =  Rim 

9f(— »)  =  A  a :  T.  Xxa :  R  a.  A(3 :  T.  Xxp :  R  (3. 

FU  [a]  (xa)  [/3]  (xp) 

»(V)  =  A+j.  Aaj  :j  — >  17.  Aa:  j  — ►  T.  A xa:Rj^n  (a). 
RV  b']+  [«j]  [a]  (*a) 

^(V*)  =  Aa :  (Vj.  (j  -*■  fi)  -*■  T) .  Axa  :  Ay,.  n  (a) . 

Ryf  [a]  (xQ) 

3i(a)  =  xQ 

5i(Aj.  r)  =  A+j.  A«j  :  j  — >  17. 5ft(r) 

»(r  [«])  =  »(r)  [|«ir^] 

3i( Aa :  /c.  r)  =  Aa :  | re| .  A.Tq,  :RKa.  9?(r) 

RK)  =  K(r)[|r'|]  (&(r')) 

^(Typerec[K]  r  of  (rint;  r_^;  rv;  r^))  = 

(fix  f :  Va :  T.  A  a  — >  A  (r*  a) . 

Aa:T.  Xxa  :Ra. 
repcase[Aa :  T.  R  (r*  a)]  xa  of 
Rint  =^'  3^(^"int) 

R^  =4>  Aa :  T.  Xxa :  R  a.  A/3 :  T.  Xxp :  R  (3. 

K(r_^)  [a]  (xQ)  [f3\  (xp) 

[t*  a]  (f  [a]  xa)  [t*  (3\  (f  [(3\  xp) 

Ry  =>■  A  j.  A a.j  :j  —>  17.  Aa:  j  — >  T.  Xxa :  Rj^n  (a). 
^(Tv)  [j]+  [aj]  [a]  (xa)  [X /3:  j.  t*  (a  (3)\ 

(A/3:  j.  X xp  :  aj  (3.  f  [a  (3\  (xa  \fi]  xp)) 

Ryf  =?•  Aa .  (Vj.  ( j  t  17)  t  T) .  Xxa  .  Ryj.  q  (a) . 

5£(v)  N  (x«)  [Av  -»•  r*  («  bl  «?)] 

(A+j.  Aaj  :  j  -»•  17.  f  [a  [j]  a,-]  (xQ  [j]+  [a^])) 

Rfl  =4>  Aa:T.  Xxa :  Ra.  4i(Tjnt) 

)[M]»(r) 

where 

T*  =  |Aa:17.Typerec[/c]  a  of  (rint;  r^;  rv;  t^-)\ 

Figure  3.18:  Representation  of  Aj  types  as  Aj)  terms 
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St(r)  (Figure  3.18)  to  construct  this  representation.  Furthermore,  type  application  gets  replaced 
by  an  application  to  a  tag,  and  to  the  term  representation  of  the  tag.  Thus  the  translations  for  type 
abstractions  and  type  applications  arc 

|  A  ar.K.  v\  =  A  a:  |k|.  Xxa  :RKa.\v\  \e  [r]|  =  |e|  [|r|]  9?(r) 

As  pointed  out  before,  the  translations  of  abstraction  and  the  fixpoint  operator  use  the  tag 
interpretation  function  F  to  map  tags  to  types. 

We  show  the  term  representation  of  types  in  Figure  3.18.  The  primitive  type  constructors  get 
translated  to  the  corresponding  term  representation.  The  representations  of  type  and  kind  functions 
are  similar  to  the  term  translation  of  type  and  kind  abstractions.  The  only  involved  case  is  the  term 
representation  of  a  Typerec.  Since  Typerec  is  recursive,  we  use  a  combination  of  a  repcase  and 
a  fix.  We  will  illustrate  only  one  case  here;  the  other  cases  can  be  reasoned  about  similarly. 

Consider  the  reduction  of  Ty  (V  — *  r").  (Ty  r  stands  for  Typerec[/>]  r  of  (r|nt;  r_^;  7y;  t  ,i  )) 
This  type  reduces  to  r_^  t' t"  (Ty  (t'))  (Ty  (r")) .  Therefore,  in  the  translation,  the  term  represen¬ 
tation  of  t_>  must  be  applied  to  the  term  representations  of  r' ,  t" ,  and  the  result  of  the  recursive 
calls  to  the  Typerec.  The  representations  of  t'  and  t"  arc  bound  to  the  variables  xa  and  xp\  by 
assumption  the  representations  for  the  results  of  the  recursive  calls  arc  obtained  from  the  recursive 
calls  to  the  function  f. 

In  the  following  propositions  the  original  Xf  kind  environment  A  is  extended  with  a  kind 
environment  A(£)  which  binds  a  type  variable  ay  of  kind  j  —>  Q  for  each  j  £  £.  Similarly  the 
term-level  translations  extend  the  type  environment  F  with  T(A),  binding  a  variable  x 0  of  type 
Rk  a  for  each  type  variable  a  bound  in  A  with  kind  n. 

Proposition  3.5.1  If  £ ;  Ahr  :  k  holds  in  Xf,  then  |£|;  |A|,  A(£)  F  |r|  :  |re|  holds  in  X ‘f. 
Proof  Follows  directly  by  induction  over  the  structure  of  r.  □ 

Proposition  3.5.2  If  £\  A  F  r  :  k  and  f;A  F  T  hold  in  Xf,  then  |£|;  |A|,  A(5);  |F|,  T(A)  F 
3?(r)  :  Rk  |r|  holds  in  A1^. 

Proof  By  induction  over  the  structure  of  r.  The  only  interesting  case  is  that  of  a  kind  application 
which  uses  Lemma  3.4.2.  □ 
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( values )  v  ::=  i  \  Xx.e  \  Wxx.v 


Rint 

R^ 

|  R_1  |  R_Ju 

1 

V  1 

1  v  1  vf 

Rv  | 

Rv  1 

Rv  1  1  |  Rv  1  1  1 

Rv  1  1  1  v 

R\F 

R/1  1 

R\L  ^  v 

Rv  1 

R/t  1 

1  Rv  1  v 

R  Pi 

R  pi  1 

1  Rpi  "f 

R*  1 

R« 1 

1  Rfi1^ 

(terms)  e  ::=  v  \  x  \  ee' 

repcass  e  of  (cmti  c_>,  ev;  eyv,  ejf) 


Figure  3.19:  Syntax  of  the  untyped  language  Xf° 


Proposition  3.5.3  If£]A]T  F  e  :  t  holds  in  A f,  then  |£|;|A|,  A(£);|r|,  T(A)  h  |e|  :  F|r| 
holds  in  Xf. 

Proof  This  is  proved  by  induction  over  the  structure  of  e,  using  Lemmas  3.4.3  and  3.4.4.  □ 


3.6  The  untyped  language 

This  section  shows  that  in  X'f.,  types  are  not  necessary  for  computation.  Figure  3.19  shows  an 
untyped  language  A^°.  We  show  a  translation  from  Xf  to  Xf°  in  Figure  3.20.  The  expression  1  is 
the  integer  constant  one. 

The  translation  replaces  type  and  kind  applications  (abstractions)  by  a  dummy  application  (ab¬ 
straction),  instead  of  erasing  them.  In  the  typed  language,  a  type  or  a  kind  can  be  applied  to  a 
fixpoint.  This  results  in  an  unfolding  of  the  fixpoint.  Therefore,  the  translation  inserts  dummy 
applications  to  preserve  this  unfolding. 

The  untyped  language  has  the  following  property  which  shows  that  term  reduction  in  Xff 
parallels  term  reduction  in  X^. 

Proposition  3.6.1  If  e  e\,  then  e°  ef. 

Proof  Follows  by  induction  over  the  reduction  relation.  □ 
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Rv°  =  Rv 


(Rv  [k]  )  =  Rv  1 


(A  j.  v)  =  \-v° 
(Aa:  k.  v)°  =  \-.v° 
(A x:t.  e)°  =  Xx.e° 
(fixx:r.  n)°  =  \\xx.v° 
(e  [Kf)°  =  e°  1 
(e[r])°  =  e°1 
(eei)°  =  e°ei° 


Rint°  =  Rint 


R^°  =  R 


(R-  M)°  =  fu 1 

(R^  [r]  e)°  =  R^  1  e° 

(R^  [r]e[r/])°  =  R^  1  e°  1 
(R_>  [r]  e  [t'\  e\)°  =  R^  1  e°  1  e\ 


(Rv[k]+[t])  =Rv11 
(Rv  [«]+[r]  [r/])0  =  Rv111 
( Rv  [k]+  [t]  [t1  ]  e )  =  Rv  1  1  1  ec 


■V0  =  fV 


(R^[r])°  =  R^1 
(R\A  M  e)°  =  R^I  e° 


R//°  =  R/t 


(rm  M)°  =  R/J 


(Rv  [r]  e)°  =  Rm  1  ec 


R  Pi°  =  RPz 
(RPz  [r])°  =  Rpz  1 
(RpZ  [t]  e)°  =  Rpi  1  e° 


Rfl°  =  R* 


(R*  M)°  =  R,  i 


(Rfl  M  e)°  =  Rh  i  e° 


(repcase[r]  e  of  (eint;  e^;  ev;  e^;  eR))°  =  repcase  e°  of  (eint°;  e^°;  ev°;  e^0;  eR° 


Figure  3.20:  Translation  of  A^  to  A^,° 


3.7  Related  work 


The  work  of  Harper  and  Morrisett  [HM95]  introduced  intensional  type  analysis  and  pointed  out  the 
necessity  for  type-level  type  analysis  operators  which  inductively  traverse  the  structure  of  types. 
The  domain  of  their  analysis  is  restricted  to  a  predicative  subset  of  the  type  language,  which  pre¬ 
vents  its  use  in  programs  which  must  support  all  types  of  values,  including  polymorphic  functions, 
closures,  and  objects.  This  chapter  builds  on  their  work  by  extending  type  analysis  to  include  the 
full  type  language.  Crary  el  al.  [CW99]  propose  a  very  powerful  type  analysis  framework.  They 
define  a  rich  kind  calculus  that  includes  sum  kinds  and  inductive  kinds.  They  also  provide  prim¬ 
itive  recursion  at  the  type  level.  Therefore,  they  can  define  new  kinds  within  their  calculus  and 
directly  encode  type  analysis  operators  within  their  language.  They  also  include  a  novel  refinement 
operation  at  the  term  level.  However,  their  type  analysis  is  “limited  to  parametrically  polymor¬ 
phic  functions,  and  cannot  account  for  functions  that  perform  intensional  type  analysis”  [CW99, 
Section  4.1],  The  type  analysis  presented  here  can  also  handle  polymorphic  functions  that  ana¬ 
lyze  the  quantified  type  variable.  Moreover,  their  type  analysis  is  not  fully  reflexive  since  they  can 
not  handle  arbitrary  quantified  types;  quantification  must  be  restricted  to  type  variables  of  kind  O. 
Duggan  [Dug98]  proposes  another  framework  for  intensional  type  analysis;  however,  he  allows 
the  analysis  of  types  only  at  the  term  level  and  not  at  the  type  level.  Yang  [Yan98]  presents  some 
approaches  to  enable  type-safe  programming  of  type-indexed  values  in  ML  which  is  similar  to 
term-level  analysis  of  types. 

The  idea  of  programming  with  iterators  is  explained  in  Pierce’s  notes  [PDM89].  Pfenning  and 
Mohring  [PL89]  show  how  inductively  defined  types  can  be  represented  by  closed  types.  They  also 
construct  representations  of  all  primitive  recursive  functions  over  inductively  defined  types. 

The  work  on  type-erasure  semantics  uses  the  framework  proposed  in  Crary  et  al.  [CWM98]. 
However,  as  we  pointed  out  before,  they  consider  a  language  that  analyzes  inductively  defined  types 
only.  Extending  the  analysis  to  arbitrary  types  makes  the  translation  much  more  complicated.  The 
splitting  of  the  type  calculus  into  types  and  tags,  and  defining  an  interpretation  function  to  map 
between  the  two,  is  somewhat  related  to  the  ideas  proposed  by  Crary  and  Weirich  for  the  language 
LX  [CW99], 

The  erasure  framework  also  resembles  the  dictionary  passing  style  in  Haskell  [PJ93].  The  term 
representation  of  a  type  may  be  viewed  as  the  dictionary  corresponding  to  the  type.  However, 
the  authors  consider  dictionary  passing  in  an  untyped  calculus;  moreover,  they  do  not  consider 
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the  intensional  analysis  of  types.  Dubois  et  al.  [DRW95]  also  pass  explicit  type  representations 
in  their  extensional  polymorphism  scheme.  However,  they  do  not  provide  a  mechanism  for  con¬ 
necting  a  type  to  its  representation.  Minamide’s  [Min97]  type-lifting  procedure  is  also  related  to 
this  work.  His  procedure  maintains  interrelated  constraints  between  type  parameters;  however,  his 
language  does  not  support  intensional  type  analysis.  Aspinall  [Asp95]  studied  a  typed  A-calculus 
with  subtypes  and  singleton  types. 
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Chapter  4 


Applying  Runtime  Type  Analysis: 
Garbage  Collection 

4.1  Introduction  and  motivation 

In  this  chapter,  we  use  fully  reflexive  type  analysis  for  building  a  type-safe  garbage  collector  (GC). 
We  show  that  analysis  of  quantified  types  is  crucial  for  accurately  modelling  the  contract  between 
the  collector  and  the  mutator.  Type-safe  GC  is  important  because  most  type-safe  systems  rely 
critically  on  the  type-safety  of  an  underlying  garbage  collector.  This  also  holds  for  Proof-Carrying 
Code  (PCC)  [Nec97]  and  Typed  Assembly  Languages  (TAL)  [MWCG98].  Indeed,  constructing  a 
verifiably  type-safe  garbage  collector  is  widely  considered  as  one  of  the  major  open  problems  in 
the  area  of  certifying  compilation  [MorOO,  CraOO]. 

A  type-safe  GC  is  not  only  desirable  from  the  point  of  view  of  safety,  but  also  for  software¬ 
engineering  purposes.  A  type-safe  GC  must  make  explicit  the  contract  between  the  collector  and 
the  mutator,  and  type-checking  makes  sure  that  this  contract  is  always  respected.  This  can  also  aid 
in  the  process  of  choosing  between  GC  variants  without  risking  the  integrity  of  the  system.  Writing 
GC  inside  a  type-safe  language  also  makes  it  possible  to  achieve  principled  interoperation  between 
garbage  collection  and  other  memory-management  mechanisms  (e.g.,  those  based  on  malloc-free 
and  regions). 

Recently,  Wang  and  Appel  [WA01]  proposed  to  tackle  the  problem  by  building  a  tracing 
garbage  collector  on  top  of  a  region-based  calculus,  thus  providing  both  type  safety  and  completely 
automatic  memory  management.  Their  approach  relies  on  monomorphization  and  defunctionaliza- 
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copy  :  VF.VT.Va.(a  — >  [T /F]a) 

Figure  4.1:  Stop-and-Copy  from  region  F  to  region  T. 


tion  (a  form  of  closure  conversion  due  to  Tolmach  [T098]).  Our  region  calculus  is  similar  to  Wang 
and  Appel,  but  we  use  runtime  type  analysis  instead  of  monomorphization.  The  system  presented 
in  this  chapter  makes  the  following  new  contributions: 

•  Wang  and  Appel’s  collector  [WA01]  relies  on  whole -program  analysis  and  code  duplication 
to  support  higher-order  and  polymorphic  languages;  this  breaks  separate  compilation.  We 
show  how  to  use  runtime  type  analysis  to  write  our  GC  as  a  library  (thus  no  code  duplication) 
and  how  to  directly  support  higher-order  polymorphic  functions. 

•  Monomorphization  is  not  applicable  in  the  presence  of  recursive  polymorphism  or  existential 
packages,  so  their  type-safe  GC  cannot  handle  languages  with  polymorphic  recursion  or 
abstract  types.  Our  system  does  not  have  this  disadvantage. 

4.1.1  The  problem 

A  region  calculus  [TT94]  annotates  the  type  of  every  heap  object  with  the  region  in  which  it  is 
allocated.  For  example,  a  pair  of  values  will  have  the  type  o\  xp  02,  where  p  is  the  region  in  which 
the  pair  is  allocated.  Thus  the  type  of  all  the  live  values  reflect  all  the  live  regions;  any  region  that 
does  not  appeal-  in  any  of  the  currently  live  types  can  be  safely  reclaimed. 

In  a  type-safe  copying  GC,  we  make  no  correctness  guarantees.  Suppose  that  the  collector  gets 
invoked  when  a  region  F  gets  filled.  Rather  than  prove  that  the  copy  function  faithfully  copies  the 
heap  to  a  new  region  T,  we  simply  show  that  it  has  the  type  Va.(a  — >  ([T /F]a))  where  ([T /F]a) 
denotes  the  type  a  with  the  region  annotation  T  substituted  for  F  (see  Fig.  4.1).  The  region  calculus 
will  then  allow  us  to  safely  reclaim  F. 
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The  main  problem  is  to  write  this  copy  function  in  a  way  that  allows  it  to  trace  through  arbitrary 
heap  structures  at  runtime,  and  to  design  a  type  system  that  is  sophisticated  enough  to  express  its 
type. 

4.1.2  Our  solution 

The  substitution  present  in  the  return  type  of  copy  as  well  as  the  need  to  observe  types  at  runtime 
leads  one  very  naturally  to  the  framework  presented  in  Chapter  3.  The  substitution  can  be  expressed 
in  a  straightforward  way  by  using  the  Typerec  construct,  while  we  can  use  the  typecase  construct 
to  inspect  types  at  runtime.  In  fact,  there  arc  only  a  few  remaining  issues  involved  in  getting  the 
right  framework. 

Consider  again  the  type  Va.(a  — ►  ([T /F]or))  of  the  copy  function.  The  type  of  an  object  grows 
every  time  it  is  copied.  If  the  object  had  the  type  a  to  begin  with,  then  the  type  changes  to  [T /F]er, 
and  then  to  fT/TJQT /F]<r)  (where  T  is  the  new  region  after  the  second  collection),  ....  Since  o 
may  contain  type  variables,  the  substitution  may  not  get  reduced  away:  [T /F \a  cannot  be  reduced 
further  until  a  is  instantiated.  In  other  words,  a  type  such  as  3a.  [T /F]a  is  a  normal  form.  This 
causes  a  problem  since  [T;/F]a  is  not  equal  to  [T//Tj  ( [T /F]a).  Thus  we  must  ensure  that  the  input 
and  output  types  of  copy  are  symmetric.  We  first  define  S p(a)  as  substituting  p  for  any  region 
annotation  and  then  redefine  copy  to  have  type  VF.VT.Va.fSpfa)  — >  Sj(a)).  This  ensures  that 
GC  does  not  increase  the  size  of  the  type  anymore,  and  also  gets  rid  of  the  special  case  before  the 
first  collection. 

The  above  solution  looks  good  until  we  try  to  copy  existential  packages  3a  £  @.cr,  that  are  used 
for  encoding  closures.  The  0  annotation  bounds  the  set  of  regions  that  can  appeal-  in  the  witness 
type  hidden  under  the  type  variable  a.  Opening  an  existential  package  of  type  3a  £  F.Sp(a),  gives 
us  the  witness  type  cr,  and  a  value  of  type  Sp(cr).  After  getting  copied  this  package  should  have 
the  type  3a  £  T.Sj(a).  Recursively  applying  copy  to  the  value  will  return  a  new  value  of  type 
S-j-(cr),  but  what  happens  to  the  witness  type?  Reusing  o  for  the  witness  type  will  not  do  since  o 
is  not  constrained  to  T  but  to  F.  A  witness  of  St(ct)  does  not  work  either;  the  only  correctly  typed 
package  we  can  produce  then  is  (a  =  Sj(cr),  v  :  a)  which  has  type  3a£T.a. 

The  problem  arises  because,  on  the  one  hand,  an  existential  type  reveals  no  information  about 
the  witness  type;  on  the  other,  we  need  to  suitably  constrain  the  region  annotation  for  the  witness 
type.  We  will  get  around  this  problem  by  defining  a  parallel  set  of  non-annotated  types  r  (that 


54 


we  will  call  tags).  The  witness  for  an  existential  type  will  now  be  a  tag.  Note  that  contrary 
to  common  practice,  our  tags  arc  not  attached  to  their  corresponding  objects  but  arc  managed 
completely  independently. 

Such  a  split  between  types  and  tags  is  reminiscent  of  the  type  system  for  predicative  languages 
where  tags  were  called  constructors  [HM95,  CW99].  But,  in  these  languages,  the  projection  from 
tags  to  types  is  essentially  an  identity  (Section  3.2.1).  Here  tags  take  on  more  significance  and  will 
be  mapped  to  actual  types  via  type-level  operators  that  enhance  the  tags  with  a  lot  more  information. 
In  essence,  this  information  encapsulates  the  constraints  that  mutator  data  has  to  satisfy  in  order 
for  the  collector  to  do  its  job. 


4.2  Source  language  Aclos 


For  simplicity  of  the  presentation,  the  source  language  we  propose  to  compile  and  garbage  collect 
is  the  simply  typed  A-calculus.  In  order  to  be  able  to  use  our  region  calculus,  we  need  to  convert 
the  source  program  into  a  continuation  passing  style  form  (CPS).  We  also  need  to  close  our  code  to 
make  all  data  manipulation  explicit,  so  we  turn  all  closures  into  existential  packages.  We  will  not 
go  into  the  details  of  how  to  do  the  CPS  conversion  [DF92]  and  the  closure  conversion  [MMH96, 
HM98]  since  the  algorithms  are  well  known. 

The  language  used  after  CPS  conversion  and  closure  conversion  is  the  language  Aclos  shown 
below. 


(types)  t 

(values)  v 

(terms)  e 

(programs)  p 


Int  |  a  |  t\  x  72  |  r  — i >  0  |  3a.r 
n  |  /  |  x  |  (vi,v2)  |  (a  =  ri,v  :  r2) 
let  x  =  v  in  e  |  let  x  =  iTiV  in  e  |  v\(v2) 

open  v  as  (a,  x)  in  e  j  halt  v 

- > 

letrec  /  =  X(x  :  r).e  in  e 


Since  functions  are  in  CPS,  they  never  return,  which  we  represent  with  the  arbitrary  return 
type  0,  often  referred  to  as  void.  The  construct  (v\ ,  n2)  represents  a  pair  while  7 lyu  selects  its  ith 
element.  To  represent  closures,  the  language  includes  existential  packages  (ot  =  T\ ,  v  :  r2)  of  type 
3<xt2.  The  abstract  type  a  hides  the  witness  type  r\.  Therefore,  the  value  v  has  the  actual  type 

[ri/a]r2.  The  construct  open  v  as  (a,  x)  in  e  takes  an  existential  package  v,  binds  the  witness  type 

- » 

to  a  and  the  value  to  x,  and  then  executes  e.  The  complete  program  letrec  fi  =  A  (a;,.  :  r, )  .e,  in  e 
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(regions) 

P 

:=  v  r 

(kinds) 

K 

:=  n  |  n  ->  n 

(tags) 

T 

:=  a  |  Int  |  n  x  72  |  r  — ►  0  |  3a. r 

|  Aa  :  K.  T  |  T\  72 

(types) 

a 

:=  int  |  <7i  x  <72  |  V[a  T re] [r](a)  — » 

1  M„(r) 

0  3a:  re.cr  u  at  p 

(values) 

V 

:=  n  |  x  \v.t  |  (vi,V2)  \  (a  =  T,v  : 

a)  A [ct  T re] [r\(x  :  a).e 

(operations) 

op 

:=  v  7 TiV  put[p]n  get  v 

(terms) 

e  : 

:=  v[t\  [p\  (v)  let  X  =  op  in  e  |  halt  V  ifgc  pe\e2 
open  v  as  (a,  x)  in  e  let  region  r  in  e  only  0  in  e 
typecase  r  of  (ej;  e^;  aia2-ex ;  cte-es) 

(normal  tags) 

t' 

:=  a\  Int  t'  — r  0  r{  x  t'2  \  3a. t' 

Aa:re.r'  ar' 

Figure  4.2:  Syntax  of  Agc 


consists  of  a  list  of  mutually  recursive  closed  function  declarations  followed  by  the  main  term  to 
be  executed. 


4.3  Target  language  Agc 

We  translate  Aclos  programs  into  our  target  language  Agc-  The  target  language  is  also  used  to  write 
the  garbage  collector.  Agc  extends  Aclos  with  regions  [TT94]  and  fully  reflexive  intensional  type 
analysis.  The  syntax  of  Accis  shown  in  Figure  4.2.  The  static  semantics  is  shown  in  Figures  4.3 
through  4.5. 

4.3.1  Functions  and  code 

Since  programs  in  Agc  are  completely  closed,  we  can  separate  code  from  data.  The  memory 
configuration  enforces  this  by  having  a  separate  dedicated  region  cd  for  all  the  code  blocks.  A 
value  A[o:  T re]['f](x  :  a).e  is  only  an  array  of  instructions  (which  can  contain  references  to  other 
values  in  cd)  and  needs  to  be  put  into  a  region  to  get  a  function  pointer  before  one  can  call  it. 
In  practice,  functions  arc  placed  into  the  cd  region  when  translating  code  from  Aclos  and  never 
directly  appeal-  in  Agc  code. 

The  indirection  provided  by  memory  references  allows  us  to  do  away  with  letrec.  For  conve¬ 
nience,  we  will  use  fix/.e  in  examples,  but  in  reality,  e  will  be  placed  at  the  location  t  in  the  cd 
region  and  all  occurrences  of  /  will  be  replaced  by  cd  We  treat  cd  as  a  special  region.  It  cannot 
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be  freed  and  can  only  contain  functions,  no  other  kind  of  data. 


4.3.2  The  type  calculus 

Since  the  garbage  collector  needs  to  know  the  type  of  values  at  runtime,  the  language  A^c  must 
support  the  runtime  analysis  of  types.  Therefore,  conceptually,  types  need  to  play  a  dual  role  in 
this  language.  As  in  the  source  language  Aclos*  they  arc  used  at  compile  time  to  type-check  well 
formed  terms.  However,  they  arc  also  used  at  runtime,  as  tags,  to  be  inspected  by  the  garbage 
collector.  To  enforce  this  distinction,  we  split  types  into  a  tag  language  and  a  type  language.  The 
tags  correspond  to  the  runtime  entity,  while  the  types  correspond  to  the  compile  time  entity. 

The  tag  for  a  value  is  constructed  during  the  translation  from  Aclos  1°  ^GC-  In  fact,  the  tags 
closely  resemble  the  Aclos  types.  We  only  need  to  add  tag-level  functions  (Act  :  n.  r)  and  tag-level 
applications  (r  T\ )  to  support  tag  analysis.  In  turn,  this  requires  adding  the  function  kind  H  — >  fi. 
The  type-level  analysis  is  done  by  the  M  operator  that  is  defined  using  a  Typerec.  As  before 
(Section  3.3.1),  we  will  use  ML-style  pattern  matching  to  define  this  type: 

Mp(lnt)  =  int 

Mp(n  x  r2)  =  (M/9(n)  x  Mp(t2))  at  p 
M/3(3a.r)  =  (3a  :  f).Mp(r))  at  p 

Mp(r  — ►  0)  =  V[][r](M,.(r))  — ■>  0  at  cd 

Mp(r)  is  the  type  corresponding  to  the  tag  r  augmented  with  region  annotations  p.  The  definition 
of  M  captures  the  invariant  that  all  objects  are  allocated  in  the  same  region. 

Types  arc  used  to  classify  terms.  The  type  language  includes  the  existential  type  for  typing 
closures  and  the  code  type  V[a][r](ff)  — ►  0  for  fully  closed  CPS  functions.  Moreover,  types  in  the 
target  language  must  include  the  region  in  which  the  corresponding  value  resides.  Therefore,  we 
use  the  notation  a  at  p  for  the  type  of  a  value  of  type  a  in  region  p. 

4.3.3  The  term  calculus 

The  term  language  must  support  region  based  memory  management  and  runtime  type  analysis. 
New  regions  arc  created  through  the  let  region  r  in  e  construct  which  allocates  a  new  region  v  at 
runtime  and  binds  r  to  it.  A  term  of  the  form  put[p]n  allocates  a  value  v  in  the  region  p.  Data  is 
read  from  a  region  in  two  ways.  Functions  arc  read  implicitly  through  a  function  call.  Data  may 
also  be  read  through  the  get  v  construct. 
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A(a)  =  k  A  h  ri  :  f2  A  F  72  :  17 
•  F  Int  :  17  Aha  :  k  A  F  T\  X  72  :  17 


Ahrj  :  O  A,a:17Fr  :  17 

Ahf->0  :  17  A  h  3a.r  :  17 

A,a:17Fr  :  17  A  F  t\  :  17  — >  17  A  F  T2  :  17 
AHA a:17.r  :  17  — >  17  A  F  t\  T2  :  17 


©;  A  F  o\  0;  A  h  (J2 
0;  A  F  int  0;  A  h  (Ji  x  CJ2 


r ;  a  T  k  h  <jj 
0;  A  F  V[a  T  k]  [r\  (a) 

0;  A  F  <7  p  E  0 


0;  A  F  cr  at  p 


0;  A,  a:K  F  <7 
)  0;  A  F  3a  :  n.a 

A  F  r  :  17  p  €  0 


0;  A  h  Mp(r ) 


Figure  4.3:  Type  and  tag  formation  rules 


Operationally,  get  takes  a  memory  address  v.l  and  dereferences  it.  Since  our  region  calculus 
does  not  admit  dangling  references,  and  since  each  reference  implicitly  carries  a  region  handle,  get 
does  not  need  a  region  argument,  as  opposed  to  put. 

Deallocation  is  handled  implicitly  through  the  only  0  in  e  construct  [WA99],  It  asserts  stati¬ 
cally  that  the  expression  e  can  be  evaluated  using  only  the  set  of  regions  in  0'  (i.e.  0  extended  with 
the  cd  region),  which  is  a  subset  of  the  regions  currently  in  scope.  At  runtime,  an  implementation 
would  treat  the  set  of  regions  in  0'  as  live  and  reclaim  all  other  regions. 

0'  =  0,  cd  tf|e,;0,;A;r|e'  I"  e  0' C  0" 

\P;  0";  A;  T  b  only  0  in  e 

The  construct  |©/  restricts  an  environment  to  the  set  of  regions  in  0',  i.e.  \P|©/  is  the  subset  of 
the  heap  restricted  to  the  regions  in  0'.  Similarly,  T|©/  eliminates  from  T  all  variables  whose  type 
refers  to  regions  not  mentioned  in  0'. 

The  use  of  only  was  chosen  for  its  simplicity.  Other  approaches  either  do  not  work  with  a 
CPS  language  or  carry  a  significant  added  complexity  to  handle  the  problem  of  aliasing.  The 
only  construct  side  steps  this  difficulty  by  making  the  actual  deletion  implicit:  instead  of  explicitly 
requesting  the  deletion  of  a  region  (say  r i),  the  program  will  request  to  keep  a  region  (say  r 2). 
At  runtime  the  system  checks  to  see  that  r \  is  not  aliased  to  r'9  and  only  then  deletes  it.  In  order 
to  trigger  GC,  ifgc  allows  us  to  check  whether  a  region  is  full.  We  will  not  consider  the  exact 
mechanism  for  implementing  this  check. 

The  runtime  type  analysis  is  handled  through  a  typecase  construct.  Depending  on  the  head  of 
the  tag  being  analyzed,  typecase  chooses  one  of  the  branches  for  execution.  When  analyzing  a 
tag  variable  a,  we  refine  types  containing  a  in  each  of  the  branches  [CWM98]. 

A  h  a  : 

\P;  0;  A;  [int/a]r  h  [int/a]e; 

'P;  0;  A;  T  h  typecase  a  of  (ej ;  e^;  a\a2.ex ;  ae.es ) 

In  the  ei  branch,  we  know  that  the  tag  variable  a  is  bound  to  Int  and  can  therefore  substitute  it 
away.  A  similar  rule  is  applied  to  the  other  cases. 

Programs  in  Agc  use  an  allocation  semantics  which  makes  the  allocation  of  data  in  memory 
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(\1/;  0;  A;  T  F  n  :  cr  ^;Q;A;ri~op  :  cT) 

T(x)  =  cr 

\F;  0;  A;  T  F  n  :  int  'F;  0;  A;  T  F  x  :  a 

ty(v.£)  =  <T  Dom{x F);  •  F  cr  at  v 
\F;  0;  A;  T  F  v.t  :  a  at  v 

cd,  r: ;  a  T  k  F  cr.j  ^lcd;cd  ,  r;  a  :  k;  x  :  a  F  e 
\F;  0;  A;  r  h  A[a  T /c][r](x  :  <j).e  :  V[aT/t][r](ff)  ->  0 

\I/;  0;  A;  T  F  v\  :  <7\  \F;  0;  A;  T  F  n2  :  cr2 

'F;©;  A;T  F  (m,n2)  :  0i  x  cr2 

^;0;A;T  h  w  :  o\  X  cr2  $;0;A;T  h  «  :  cr  at  p 

0;  A;  T  h  7Ti?;  :  cr,;  'I';  0;  A;  T  F  get  n  :  cr 

Ahr  :  k  $;0;A;Tht;  :  [r/ajcr 
0;  A;  V  F  (a=T,  v  :  a)  :  3a  :  k.o 

f;0;A;ri-u  :  cr  p  £  0 
'F;©;  A;T  F  put[p]w  :  cr  at  p 

Figure  4.4:  Formation  rules  for  Xqq  values 
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(^;0;A;rhe) 


\P;@;A;rbi;  :  V[a  r«][r]  (it) —>  0  at  p 

*P;  0;  A;  T  b  Vi  :  [p,  f/r ,  a]<r,:  Ahr,:  :  pi  G  0 

©;  A;  r  b  v[r]  [#](#) 

$;0;A;Tb  op  :  cr  \P;  0;  A;  T,  x  :  a  b  e 
\P;  0;  A;  T  b  let  x  =  op  in  e 

^;0;A;r  b  «  :  3a'  :  k.o  \P;  0;  A,  a  :  re;  T, x  :  [a/a']a  b  e 

'P;  0;  A;  r  b  open  v  as  (a,  x)  in  e 

^;0;A;rbei  fr;0;A;rbe2  pG0 
'P;  0;  A;  T  b  ifgc  p  e\  e2 

\P;  0,  r;  A;  r  b  e  $;0;A;rbi;  :  int 

*P;  0;  A;  T  b  let  region  r  in  e  'P;  0;  A;  T  b  halt  v 

'P|e,;0/,cd;A|ei;r|ei  b  e  0lc9 
\P;  ©;  A;T  b  only  0'  in  e 

*P;  0;  A;  T  b  ej 

0;  A;T  b  typecase  Int  of  (ej ;  e^;  a\ a2.ex ;  ae.e3) 

_ *P;  0;  A;  T  b  e^ _ 

'P;  0;  A;T  b  typecase  f  — >  0  of  (ej ;  e^;  aia2.ex ;  ae.e3) 

_ 'P;©;  A;T  b  [Ti,T2/ai,a2]ex _ 

\P;  ©;  A;T  b  typecase  (n  x  r2)  of  (ej;  e^;  aia2.ex ;  ae.es) 

'P;  0;  A;  T  b  [Aaxbb  T/ae]es 
'P;  0;  A;  r  b  typecase  3a. T  of  (ej;  e^;  «ia2.ex ;  ae.e3) 

A  b  a  :  bt 

VP;  0;  A;  [int/a]r  b  [int/a]ej 
'P;  0;  A;  T  b  e^ 

'P;  0;  A,  a\  :  bi,  a2  :  bt;  [a\  x  a2/a]r  b  [a\  x  a2/a]ex 
*P;  0;  A,  ae  :  bt  — >  bt;  [3abae  a'/ajT  b  [3abae  a//a]e3 

'P;  0;  A;  r  b  typecase  a  of  (ej;  e^;  «ia2.ex ;  ae.e3) 

Figure  4.5:  Term  formation  rules  of  Agc- 
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(Af,  ul[f\[p ](«)) 

(Af,  z/i[r'][p](v)) 

where  M(v.f)  =  (A[aT Zv][r](x  :  <r).e) 

(Af,  let  x  =  v  in  e) 

(Af,  let  x  =  7Tj(?;i,  U2)  in  e) 

(Af,  let  x  =  put[^]x  in  e) 
where  t  ^  Dom{M{u)) 

(Af,  let  x  =  get  z/f  in  e) 

(Af,  open  (a  =  r,v  :  a)  as  (a,  x)  in  e) 

(Af,  open  (a=r',v  :  a)  as  (a,x)  in  e) 

(Af,  ifgc  p  ei  e2) 

(Af,  ifgc  p  ei  e2) 

(Af,  let  region  r  in  e) 
where  i/  0  Dom(M) 

(Af,  only  0  in  e) 

(Af,  typecase  r  of  (ej;  e^;  aia2.ex ;  ae.e3)) 
(Af,typecase  Intof  (ej;e^;aia2.ex;ae.e3)) 


^  (M,  i'4r/][p]('u)) 

(Af ,  e[p,r'  ,v/ r ,  a,  x] ) 

(Af,  e[v/x]) 

(Af,  e[t;j/x]) 

(M{u.£  t-s-  x},  [zx£/x]e) 

(Af,  [x/x]e)  where  M(v.£)  =  x 
(Af,  open  ( a=r',v  :  a)  as  (a,x)  in  e) 
^  (Af,  e[r',  v/a,  x]) 

(Af ,  ei )  if  p  is  full 
^  (Af,  e2)  if  p  is  not  full 

(M{^  ^  {}}>e[i//r]) 

^  (Af|e,  e) 

(Af,  typecase  r'  of  (ej;  e^;  aia2.ex;  ae.e3)) 
(Af,  ef) 


(Af,  typecase  r  — >  0  of  (ej;  e^;  aia2.ex ;  ae.eg))  (Af,  e_>) 

(Af,  typecase  Ti  x  r2  of  (ej;e^;aia2.ex;ae.e3))  (Af,  [n,  r2/ai,  a2]ex) 
(Af,  typecase  3a. T  of  (ej;e^;aia2.ex;ae.e3))  (Af ,  [Aa :  if.  r/ae je^) 

Figure  4.6:  Operational  semantics  of  Aqc 


explicit.  The  operational  semantics,  defined  in  Fig.  4.6,  maps  a  machine  state  P  to  a  new  machine 
state  P' .  A  machine  state  is  a  pair  (Af ,  e)  of  a  memory  Af  and  a  term  e  being  executed.  A  memory 
consists  of  a  set  of  regions;  hence,  it  is  defined  formally  as  a  map  between  region  names  u  and 
regions  R.  A  region,  in  turn,  is  a  map  from  offsets  £  to  storable  values  v.  Therefore,  an  address 
is  given  by  a  pair  of  a  region  and  an  offset  v.l.  We  assign  a  type  to  every  location  allocated  in  a 
region  with  the  memory  environment  T.  Figure  4.7  shows  the  form  of  environments. 

The  language  A^c  obeys  the  following  properties.  The  proofs  arc  given  in  Appendix  B. 

Proposition  4.3.1  (Type  Preservation)  If  F  (Af,  e)  and  (Af,  e)  ^  (Af ',  e')  then  F  (Af',  e'). 

Proposition  4.3.2  (Progress)  If\~  (Af,  e)  then  either  e  =  halt  v  or  there  exists  a  (Af ',  e')  such 
that  (Af,  e)  (Af',  e'). 


62 


0  b  T  b  'T 


_ Q; •  l~  Qj _  Tj 

0  b  lx  :  C7i,,..  ,£n  :  an  b  ui  :  Ti, . . , ,  vn  :  Tn 

Tcd  =  ^  :  V[n][rl](vTTot)  -»•  0, ...  ,4  :  V|*p=^)  -►  0 


.  b  R  :  T  bM:$ 


_ 'I';  Dom(f);  •;  •  b  Vj  :  _ 

^  \~  vi,...,£n^  vn  :  4  :  ct!,.  . .  ,4  :  crn 

b  z/j  :  Tj, . . . ,  vn  :  Tn  :  Ti, . . . ,  vn  :  Tn  b  R,  :  T/ 

b  V!  h->  R1, . . . ,  un  i— »•  Rn  :  vi  :  Ti, . . . ,  vn  :  Tn 


Figure  4.7:  Environment  formation  rules. 


4.4  Translating  Aclos  to  Agc 

The  translation  of  terms  from  Aclos  to  Agc  (Fig-  4.8)  is  mostly  directed  by  the  type  translation  Mp 
presented  earlier:  each  function  takes  the  current  region  as  an  argument  and  begins  by  checking  if 
a  garbage  collection  is  necessary.  All  operations  on  data  arc  slightly  rewritten  to  account  for  the 
need  to  allocate  them  in  the  region  or  to  fetch  them  from  the  region.  For  example  a  Aclos  function 
like: 

fix  swap(x  :  Int  x  Int). 

let  xl  =  mx  in  let  x2  =  n2x  in  let  x'  =  (x2,  xl)  in  halt  0 
will  be  turned  into  the  following  Ace  function: 

cdl  =  A[][r](x  :  (int  x  int)  at  r). 

ifgc?’  (gc[lnt  x  lnt][r](cdT,  x)) 

let  x  =  get  x  in 

let  xl  =  n±x  in 
let  x2  =  7 r2x  in 
let  x'  =  put[r](.x2,  xl)  in 

halt  0 

The  mapping  between  Aclos  identifiers  like  swap  and  Ace  location  like  ed.f  is  kept  in  the 
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[F  I-  AclOS  =>-  Agc) 

F  hv  n  =$■  n  Fh„/4  cd.F(f)  F  hv  x  =>•  x 


F  h„  «i  4  v[  F  hv  V2  =$■  v'2 
F  hv  (vi,v2)  =>  put[r](u/1,  ^2) 

F  hv  v  =4>  v' 

F  hv  (a  =  Ti,  v  :  t2)  =>  put[r](a  =  ri,  v'  :  Mr(r2)) 

F  hv  v\  =$■  v[  F  \-v  v2  v'2  F  hv  v  v' 

F  he  vi(v2)  =>  uiDHK)  F  b e  halt  v  =>  halt  v' 

F  be  e  =>•  F  F  b„  »  4  »' 

F  be  open  v  as  (a,  x)  in  e  =^-  open  (get  ?/)  as  (a,  x)  in  F 

F  be  e  F  F  hvv=$-v' 

F  be  let  x  =  v  in  e  =>  let  x  =  F  in  F 

F  be  e  F  F  hv  v  =£-  F 
F  be  let  x  =  Tiiv  in  e  =Het  x  =  7rj(get  F)  in  F 

_ Fhee^F  e  =  F(f) _ 

Ff  (/  =  A(x  :  r).e) 

=$■  A[][r](x  :  Mr(r)).ifgc  r  {gc[r\  [r]  (cd.F,  x))  F 


F  —  fi  1— ►  i\,  ■  ■  ■  ,  fn  l— ^ 

Fhf  fi  =  A  (xj  :  Tj).ej  =>  /■  Fbee4e' 

bp  letrec/j  =  A(x« :  n)^  in  e 

=>  (cd  !->•  i\  !->•  let  region  r  in  e') 

Figure  4.8:  Translation  of  Aclos  terms. 
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fix  gc[a  :  fi][n](/  :  V[][r](Mr(a))  -*■  0,x  :  Mri(a)). 
let  region  r2  in 
let  y  =  copy[a][ri,r2](x)  in 
only  ri  in  f\\[r2]{y) 

fix  copy[a  :  fi]  [n ,  r2]  (x  :  Mri(a))  :  Mr2(a). 

typecase  a  of 
Int  x 

— >  X 

a±  x  «2  =>  let  x’i  =  copy[a\][ri,  r2](7ri(get  x))  in 
let  x 2  =  copy [a2]  [n,  ^2] (7T2 (get  x))  in 

put[r2](xi,x2) 

3ae  =>  open  (get  x)  as  (a,  y)  in 

let  2:=  copy[ae  a]  [r\ ,  r2]  (y)  in 
put[r2](a  =  a,  2  :  Mr2(aea)) 

Figure  4.9:  The  garbage  collector  proper. 


environment  F.  The  region  aigumcnt  r  refers  to  the  current  region.  It  is  initially  created  at  the  very 
beginning  of  the  program  and  is  changed  after  each  garbage  collection. 

An  important  detail  here  is  that  the  garbage  collector  receives  the  tag  r  rather  than  the  type  a 
of  the  argument.  The  GC  receives  the  tags  for  analysis  as  they  were  in  Aclos  rather  than  as  they 
arc  translated  in  A^c- 

To  make  the  presentation  simpler,  the  garbage-collection  code  in  Fig.  4.9  uses  some  syntactic 
sugar  and  resorts  to  a  direct-style  presentation  of  the  copy  function.  In  [MSSOO]  we  show  the 
same  code  after  CPS  and  closure  conversion.  The  conversion  does  not  present  any  new  technical 
difficulties,  but  just  makes  the  code  a  lot  harder  to  understand.  We  will  therefore  stick  to  the 
direct  style  presentation  here.  The  garbage  collector  itself  is  very  simple:  it  first  allocates  the  to 
region,  asks  copy  to  move  everything  into  it  and  then  frees  the  from  region  before  jumping  to  its 
continuation  (which  uses  the  new  region). 

The  copy  function  is  similarly  straightforward,  recursing  over  the  whole  heap  and  copying  in  a 
depth-first  way.  The  direct  style  here  hides  the  stack.  When  the  code  is  CPS  converted  and  closed, 
we  have  to  allocate  that  stack  of  continuations  in  an  additional  temporary  region  and  unless  our 
language  is  extended  with  some  notion  of  stack,  none  of  those  continuations  would  be  collected 
until  the  end  of  the  whole  garbage  collection.  The  size  of  this  temporary  region  can  be  bounded  by 
the  size  of  the  to  region  since  we  can’t  allocate  more  than  one  continuation  per  copied  object,  so  it 
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is  still  algorithmically  efficient,  although  this  memory  overhead  is  a  considerable  shortcoming. 


4.5  Summary  and  related  work 

In  this  chapter,  we  focussed  on  a  simple  stop-and-copy  collector.  In  separate  work  [MSS01]  we 
have  shown  how  to  augment  the  system  presented  here  to  support  forwarding  pointers  and  genera¬ 
tional  collection.  In  both  these  cases,  type  analysis  (specifically  the  Typerec  operator  on  quantified 
types)  is  crucial  to  capturing  the  invariants  that  the  mutator  must  satisfy.  There  arc  still  some  more 
issues  that  remain  to  be  solved  before  we  can  implement  a  type-safe  industrial-strength  garbage 
collector.  For  example,  our  generational  scheme  is  feasible  only  in  a  language  where  side-effects 
arc  rare.  Our  scheme  also  does  not  handle  cyclic  data  structures.Nevertheless  we  believe  that  our 
current  contributions  constitute  a  significant  step  towards  the  goal  of  providing  a  practical  type-safe 
garbage  collector. 

Wang  and  Appel  [WA99]  proposed  to  build  a  tracing  garbage  collector  on  top  of  a  region- 
based  calculus,  thus  providing  both  type  safety  and  completely  automatic  memory  management. 
They  rely  on  a  closure  conversion  algorithm  due  to  Tolmach  [T098]  that  represents  closures  as 
datatypes.  This  makes  closures  transparent,  making  it  easier  for  the  copy  function  to  analyze, 
but  it  requires  whole  program  analysis.  We  believe  it  is  more  natural  to  represent  closures  as 
existentials  [MMH96,  HM98]  and  we  show  how  to  use  intensional  analysis  of  quantified  types  to 
typecheck  the  GC-copy  function. 

Tofte  and  Talpin  [TT94]  proposed  to  use  region  calculus  to  type  check  memory  management 
for  higher-order  functional  languages.  Crary  et  al  [CWM99]  presented  a  low-level  typed  inter¬ 
mediate  language  that  can  express  explicit  region  allocation  and  deallocation.  Our  A  qc  language 
borrows  the  basic  organization  of  memories  and  regions  from  Crary  et  al  [CWM99].  The  main 
difference  is  that  we  don’t  require  explicit  capabilities — region  deallocation  is  handled  through  the 
only  primitive. 
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Chapter  5 


Integrating  Runtime  Type  Analysis 
With  a  Proof  System 

5.1  Introduction 

Until  now  we  have  considered  type  analysis  in  a  system  where  we  can  only  certify  conventional 
type-safety.  However,  certifying  compilation  as  originally  envisaged  by  Necula  and  Lee  [NL96, 
Nec97]  through  their  proof  carrying  code  (PCC)  framework,  can  be  used  to  certify  complex  spec¬ 
ifications  [Nec98,  AFOOa],  For  example,  the  Foundational  PCC  system  [AFOOb]  can  certify  any 
property  expressible  in  Church's  higher-order  logic. 

In  this  chapter  we  describe  a  type  system  that  supports  both  runtime  type  analysis  and  the 
explicit  representation  of  proofs  and  propositions.  As  far  as  we  know,  our  work  is  the  first  com¬ 
prehensive  study  on  how  to  integrate  higher-order  predicate  logic  and  type  analysis  into  typed 
intermediate  languages.  Existing  type-based  certifying  compilers  [NL98,  CLN+00]  have  focused 
on  simple  memory  and  control-flow  safety  only.  Typed  intermediate  languages  [HM95]  and  typed 
assembly  languages  [MWCG98]  also  do  not  rival  the  expressiveness  of  the  logic  used  in  some  PCC 
systems  [AFOOb]. 

This  chapter  builds  upon  a  large  body  of  previous  work  in  the  logic  and  theorem-proving  com¬ 
munity  [Bar99,  Bar91],  but  makes  the  following  new  contributions: 

•  We  show  how  to  design  new  typed  intermediate  languages  that  arc  capable  of  representing 
and  manipulating  propositions  and  proofs.  We  show  how  these  propositions  can  enforce 
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more  sophisticated  program  invariants.  For  example,  we  can  assign  an  accurate  type  to 
unchecked  vector  (or  array)  access  (see  Section  5.5.2).  Xi  and  Pfenning  [XP99]  can  achieve 
the  same  using  constraint  checking,  but  their  system  does  not  support  arbitrary  propositions 
and  (explicit)  proofs,  so  it  is  less  general  than  ours. 

•  We  show  how  to  support  fully  reflexive  type  analysis  in  such  a  type  system.  We  achieve  this 
by  using  inductive  definitions  to  define  the  base  kind  (the  kind  containing  the  types  of  terms). 
In  a  sense  it  generalizes  the  work  presented  in  Chapter  3. 

•  We  give  rigorous  proofs  for  the  meta-theoretic  properties  (subject  reduction,  strong  normal¬ 
ization,  confluence,  and  consistency  of  the  underlying  logic)  of  our  type  system. 


5.2  Approach 

Before  getting  into  the  details,  we  first  establish  a  few  naming  conventions  (Figure  5.1).  Until  now, 
our  typed  intermediate  languages  had  three  levels.  We  will  now  require  a  fourth  level  which  we 
call  kind  schema  ( kscm ).  We  divide  the  typed  intermediate  language  into  a  type  sub-language  and  a 
computation  sub-language.  The  type  language  contains  the  top  three  levels.  Kind  schemas  classify 
kind  terms  while  kinds  classify  type  terms.  We  often  say  that  a  kind  term  k  has  kind  schema  u, 
or  a  type  term  r  has  kind  k.  We  assume  all  kinds  used  to  classify  type  terms  have  kind  schema 
Kind,  and  all  types  used  to  classify  expressions  have  kind  Q.  For  example,  both  the  function  type 
7~i  — >  t 2  and  the  polymorphic  type  Vo- :  n.  r  have  kind  O.  Following  the  tradition,  we  sometimes 
say  “a  kind  n”  to  imply  that  k  has  kind  schema  Kind,  “a  type  r”  to  imply  that  r  has  kind  Q,  and  “a 
type  constructor  r”  to  imply  that  r  has  kind  “k  — >  •  •  •  — >  Q.”  Kind  terms  with  other  kind  schemas, 
or  type  terms  with  other  kinds  are  strictly  referred  to  as  “kind  terms”  or  “type  terms.” 

The  computation  language  is  the  lowest  level  which  is  where  we  write  the  actual  program.  This 
language  will  eventually  be  compiled  into  machine  code.  We  often  use  names  such  as  computation 
terms,  computation  values,  and  computation  functions  to  refer  to  various  constructs  at  this  level. 

5.2.1  Representing  propositions  and  proofs 

The  first  step  is  to  represent  propositions  and  proofs  for  a  particular  logic  in  a  type-theoretic  setting. 
The  most  established  technique  is  to  use  th e  fo rm u lae-as- types  principle  (a.k.a.  the  Curry- Howard 
correspondence)  [How80]  to  map  propositions  and  proofs  into  a  typed  A-calculus.  The  essential 
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THE  TYPE  LANGUAGE: 


(, kscm )  u  ::  =  Kind  |  . . . 

(kind)  k  ::=  n\— >k,2  |  ^  |  •  •  • 

(type)  t  ::=  a  |  Act:  k.  t  |  n  T2  |  T\  — >T2  |  Va:  k.  t  |  . . . 

THE  COMPUTATION  LANGUAGE: 

(exp)  e  ::=  x  \  Xx:  t.  e  \  e\  e^  |  Aa  :n.e  |  e[r]  |  . . . 

Figure  5.1:  Typed  intermediate  language  -  notations 


idea,  which  is  inspired  by  constructive  logic,  is  to  use  types  (of  kind  17)  to  represent  propositions, 
and  expressions  to  represent  proofs.  A  proof  of  an  implication  P  D  Q  is  a  function  object  that  yields 
a  proof  of  proposition  Q  when  applied  to  a  proof  of  proposition  P.  A  proof  of  a  conjunction  P  f\Q 
is  a  pair  (e\ ,  62)  such  that  e\  is  a  proof  of  P  and  e 2  is  a  proof  of  Q.  A  proof  of  disjunction  P\/Q  is  a 
pair  (6,  e) — a  tagged  union — where  b  is  either  0  or  1  and  if  b  =  0,  then  e  is  a  proof  of  P;  if  b  =  1  then 
e  is  a  proof  of  Q.  There  is  no  proof  for  the  false  proposition.  A  proof  of  a  universally  quantified 
proposition  Mx£B ,P(x)  is  a  function  that  maps  every  element  b  of  the  domain  B  into  a  proof  of 
P(b)  where  P  is  a  unary  predicate  on  elements  of  B.  Finally,  a  proof  of  an  existentially  quantified 
proposition  3x£B ,P(x)  is  a  pair  (b,  e )  where  b  is  an  element  of  B  and  e  is  a  proof  of  P(b).  Proof¬ 
checking  in  the  logic  now  becomes  typechecking  in  the  corresponding  typed  A-calculus.  There  has 
been  a  large  body  of  work  done  along  this  line  in  the  last  30  years;  most  type-based  proof  assistants 
are  based  on  this  fundamental  principle.  Barendregt  et  al.  [Bar99,  Bar91]  give  a  good  survey  on 
previous  work  in  this  area. 

Unfortunately,  the  above  scheme  fails  to  work  in  the  context  of  typed  intermediate  languages. 
The  problem  arises  because  representing  predicates  introduces  dependent  types.  For  example,  sup¬ 
pose  Nat  is  the  domain  for  natural  numbers  and  Prime  is  a  unary  predicate  that  asserts  an  element 
of  Nat  as  a  prime  number.  To  represent  this  in  a  typed  setting,  we  need  a  type  nat  representing 
Nat,  and  a  type  constructor  prime  representing  Prime.  This  type  constructor  must  take  a  number 
as  an  argument  (to  check  whether  it  is  prime):  therefore  the  type  constructor  is  dependent  on  values 
and  has  the  kind  nat— >  Q. 

Dependent  types  introduce  problems  when  used  in  a  typed  intermediate  language.  First,  real 
programs  often  involve  effects  such  as  assignment,  I/O,  or  non-termination.  Effects  interact  badly 
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with  dependent  types.  It  is  possible  to  use  the  effect  discipline  [SG90]  to  force  types  to  be  de¬ 
pendent  on  pure  computation  only,  but  this  does  not  work  in  some  typed  A-calculi;  for  example,  a 
“pure”  term  in  Girard’s  XU  [Gir72]  could  still  diverge.  Second,  many  type  preserving  compilers 
perform  typed  CPS  conversion  [MWCG98],  but  in  the  presence  of  dependent  types,  this  is  a  very 
difficult  problem  [BHS99].  Third,  it  is  important  to  maintain  a  phase  distinction  between  compile¬ 
time  typechecking  and  run-time  evaluation.  Having  dependent  types  makes  it  harder  to  preserve 
this  property. 

5.2.2  Separating  the  type  and  computation  languages 

We  solve  these  problems  by  making  sure  that  our  type  language  is  never  dependent  on  the  compu¬ 
tation  language.  Because  the  actual  computation  term  has  to  be  compiled  down  to  assembly  code 
in  any  case,  it  is  a  bad  idea  to  treat  it  as  paid  of  types.  This  separation  immediately  gives  us  back 
the  phase-distinction  property. 

To  represent  propositions  and  proofs,  we  lift  everything  one  level  up:  we  use  kinds  to  represent 
propositions,  and  type  terms  for  proofs.  The  domain  Nat  is  represented  by  a  kind  Nat;  the  predicate 
Prime  is  represented  by  a  dependent  kind  term  Prime  which  maps  a  type  term  of  kind  Nat  into  a 
proposition.  A  proof  for  proposition  Prime(ro)  certifies  that  the  type  term  n  is  a  prime  number. 

To  maintain  decidable  typechecking,  we  insist  that  the  type  language  is  strongly  normalizing 
and  free  of  side  effects.  This  is  possible  because  the  type  language  no  longer  depends  on  any 
runtime  computation.  Essentially,  we  circumvent  the  problems  with  dependent  types  by  replacing 
them  with  dependent  kinds. 

To  reason  about  actual  programs,  we  still  have  to  connect  terms  in  the  computation  language 
with  those  in  the  type  language.  We  follow  Xi  and  Pfenning  [XP99]  and  use  singleton  types  [Hay91] 
to  relate  computation  values  to  type  terms.  In  the  previous  example,  we  introduce  a  singleton  type 
constructor  snat  of  kind  Nat  — >  Q.  Given  a  type  term  n  of  kind  Nat,  if  a  computation  value  v  has 
type  snat(n),  then  v  denotes  the  natural  number  represented  by  n. 

A  certified  prime  number  package  now  contains  three  parts:  a  type  term  n  of  kind  Nat,  a  proof 
for  the  proposition  Prime(ro),  and  a  computation  value  of  type  snat(n).  We  can  pack  it  up  into  an 
existential  package  and  make  it  a  first-class  value  with  type: 

3n:Nat.3a:Prime(n).snat(?r). 
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Here  we  use  3  rather  than  S  to  emphasize  that  types  and  kinds  arc  no  longer  dependent  on  com¬ 
putation  terms.  Under  the  erasure  semantics  this  certified  package  is  just  an  integer  value  of  type 
snat(ro)  at  run  time. 

We  can  also  certify  programs  that  involve  effects.  Assume  again  that  /  is  a  function  in  the 
computation  language  which  may  not  terminate  on  some  inputs.  Suppose  we  want  to  certify  that 
if  the  input  to  /  is  a  prime,  and  the  call  to  /  does  return,  then  the  result  is  also  a  prime.  We  can 
achieve  this  in  two  steps.  First,  we  construct  a  type-level  function  g  of  kind  Nat  — ►  Nat  to  simulate 
the  behavior  of  /  (on  all  inputs  where  /  does  terminate)  and  show  that  /  has  the  following  type: 

Vn:  Nat.  snat(n)  — ►  snat(g(ra)) 

Here  following  Figure  5.1,  we  use  V  and  — >  to  denote  the  polymorphic  and  function  types  for  the 
computation  language.  The  type  for  /  says  that  if  it  takes  an  integer  of  type  snat(ra)  as  input  and 
does  not  loop  forever,  then  it  will  return  an  integer  of  type  snat (g(n)).  Second,  we  construct  a 
proof  Tp  showing  that  g  always  maps  a  prime  to  another  prime.  The  certified  binary  for  /  now  also 
contains  three  parts:  the  type-level  function  g,  the  proof  tp,  and  the  computation  function  /  itself. 
We  can  pack  it  into  an  existential  package  with  type: 

3g:  Nat-> Nat.  3p:  (Ut:  Nat.Prime(V)  — ■> Prime(p(t))). 

Vn: Nat.  snat (n)  — ►  snat(g(ra)) 

Notice  this  type  also  contains  function  applications  such  as  g(n),  but  g  is  a  type-level  function 
which  is  always  strongly  normalizing,  so  typechecking  is  still  decidable. 

5.2.3  Designing  the  type  language 

We  can  incorporate  propositions  and  proofs  into  a  type  system,  but  in  addition  the  type  language 
must  fulfill  its  usual  responsibilities.  First,  it  must  provide  a  set  of  types  (of  kind  Q)  to  classify  the 
computation  terms.  Second,  it  must  support  the  intensional  analysis  of  these  types. 

Our  approach  to  this  is  to  generalize  the  solution  (for  type  analysis)  given  in  Chapter  3.  There 
we  introduced  kind  polymorphism  so  that  the  types  could  be  defined  in  a  way  that  made  the  base 
kind  inductive.  Here  we  will  go  a  step  further  and  provide  a  general  mechanism  of  defining  induc¬ 
tive  kinds.  The  base  kind  O  is  then  defined  inductively  using  this  mechanism.  Inductive  definitions 
also  greatly  increase  the  programming  power  of  our  type  language.  We  can  introduce  new  data  ob- 
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( kscm )  u  ::=  z  \  Ha:  k.  u  |  II  j  :u\.  ui  |  Kind 

(kind)  k  ::=  j  \  Xa:  K\.  k2  \  k\t\  Xj :  u.  k  \  K\  k2  I  Ha:  K\.  k2  I  Hj :  u.  k 
|  n^:Kscm.  k  |  lnd(j:Kind){K}  |  Elim[K/,«](r){K} 

(type)  t  ::=  a  \  Xa:  k.  t  \  T\  r2  |  Xj  :u.  r  |  t[k\  \  X z :  Kscm.  r  |  t[u\ 

|  Ctor(i,  k)  j  Elimf^',  k](t'){t} 

Figure  5.2:  Syntax  of  Xlcc 


jects  ( e.g integers,  lists)  and  define  primitive  recursive  functions,  all  at  the  type  level;  these  in  turn 
are  used  to  help  model  the  behaviors  of  the  computation  terms. 

In  the  rest  of  this  chapter,  we  first  give  a  formal  definition  of  our  type  language  (which  will  be 
named  as  Xlcc  from  now  on)  in  Section  5.3.  To  show  how  this  type  system  can  be  used,  we  then 
present  a  sample  computation  language  A h  in  Section  5.5. 

5.3  The  type  language  \lcc 

Our  type  language  Xlcc  resembles  the  calculus  of  inductive  constructions  (Cic)  implemented  in  the 
Coq  proof  assistant  [  HPM  1  00],  We  do  not  directly  use  Cic  as  our  type  language  for  the  following 
reasons:  first,  Cic  contains  some  features  designed  for  program  extraction  [Pau89]  which  arc  not 
required  in  our  case  (where  proofs  arc  only  used  as  specifications  for  the  computation  terms). 
Second,  as  far  as  we  know,  there  arc  still  no  formal  studies  covering  the  entire  Cic  language. 

The  syntax  for  Xlcc  is  shown  in  Figure  5.2.  Here  kind  schemas  (kscm)  classify  kind  terms 
while  kinds  classify  type  terms.  There  arc  variables  at  all  three  levels:  kind-schema  variables  z, 
kind  variables  j,  and  type  variables  a.  We  have  an  external  constant  Kscm  classifying  all  the  kind 
schemas;  essentially,  X'cr  has  an  additional  level  above  kscm ,  of  which  Kscm  is  the  sole  member. 

A  good  way  to  comprehend  Xlcc  is  to  look  at  its  five  n  constructs:  there  arc  three  at  the  kind 
level  and  two  at  the  kind-schema  level.  Each  n  term  is  used  to  typecheck  a  A-function  and  its 
application  form  defined  at  a  level  below.  We  use  a  few  examples  to  explain  why  each  of  them  is 
necessary.  Following  the  tradition,  we  use  arrow  terms  (e.g.,  n  \  —>  k2)  as  a  syntactic  sugar  for  the 
non-dependent  n  terms  (e.g.,  ITo  :  n  ] .  k2  is  non-dependent  if  a  does  not  occur  free  in  k2). 

•  Kinds  no  :  n  i .  k2  and  K\  — >  k2  arc  used  to  typecheck  the  type-level  function  A  a:  k.t  and 
its  application  form  n  r2.  Assuming  Q  and  Nat  arc  inductive  kinds  (defined  later),  we  can 
write  a  type  term  such  as  Xa :  H.  a  which  has  kind  Q  — >  ft,  or  a  type-level  arithmetic  function 
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such  as  plus  which  has  kind  Nat  — >  Nat  — >  Nat. 

•  Kinds  II j :  u.  k  and  u  — r  k  arc  used  to  typecheck  the  type-level  kind  abstraction  A j :  u.  r  and 
its  application  form  t[k].  As  we  saw  before,  this  is  needed  to  support  intensional  analysis  of 
quantified  types.  It  can  also  be  used  to  define  logic  connectives  and  constants,  e.g. 

True  :  Kind  =  II/':  Kind. j 

False  :  Kind  =  II/':  Kind. j 

True  has  the  polymorphic  identity  as  a  proof: 

id  :  True  =  \j:K\nd.Xa:j.a 

but  False  is  not  inhabited  (this  is  essentially  the  consistency  property  of  Xlcc  which  we  will 
show  later). 

•  Kind  Ylz :  Kscm .  n  is  used  to  typecheck  the  type-level  kind-schema  abstraction  A 2 :  Kscm.  r 
and  its  application  form  r[u].  This  is  not  in  the  core  calculus  of  constructions  [CH88].  We 
use  it  in  the  inductive  definition  of  ft  (see  Section  5.5)  where  both  the  VKscm  and  ^Kscm 
constructors  have  kind  Hz :  Kscm.  (z  — >fl)— These  two  constructors  in  turn  allow  us  to 
typecheck  predicate -polymorphic  computation  terms,  which  occurs  during  closure  conver¬ 
sion  [SSTP01], 

•  Kind  schemas  IT  a  :  k.  u  and  re— » u  are  used  to  typecheck  the  kind-level  type  abstraction  A  a  : 
K  \ .  k.‘2  and  its  application  form  k[t}.  The  predicate  Prime  has  kind  schema  Nat— >  Kind.  A 
predicate  with  kind  schema  Ila :  Nat.  Prime(o)  — >  Kind  is  only  applicable  to  prime  numbers. 
We  can  also  define  e.g.  a  binary  relation: 

LT  :  Nat->  Nat Kind 

so  that  LT  cri  a 2  is  a  proposition  asserting  that  the  natural  number  represented  by  a  1  is  less 
than  that  of  «2- 

•  Kind  schemas  Ilj  :  u  1 .  a.  2  and  u  \  — r  11 2  arc  used  to  typecheck  the  kind-level  function  A  j  : 
u.  k  and  its  application  form  K\  k-2-  We  use  it  to  write  higher-order  predicates  and  logic 
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connectives.  For  example,  the  logical  negation  operator  can  be  written  as  follows: 


Not  :  Kind  — »  Kind  =  \j:  Kind,  (j— > False) 

The  consistency  of  \lcc  implies  that  a  proposition  and  its  negation  cannot  be  both  inhabited — 
otherwise  applying  the  proof  of  the  second  to  that  of  the  first  would  yield  a  proof  of  False. 

\lcc  also  provides  a  general  mechanism  of  inductive  definitions  [Pau93].  The  term  lnd(j  : 
Kind) {£}  introduces  an  inductively  defined  kind  j  containing  a  list  of  constructors  whose  kinds 
arc  specified  by  ft.  Here  j  must  only  occur  “positively”  (Section  5.4)  inside  each  ft,.  The  term 
Ctor  (i.  ft)  refers  to  the  i-th  constructor  in  an  inductive  kind  ft.  For  presentation,  we  will  use  a  more 
friendly  syntax  in  the  rest  of  this  chapter.  An  inductive  kind  I  =  I n d ( j  :  Kind){ft}  will  be  written 
as  shown  below.  We  give  an  explicit  name  c,  to  each  constructor,  so  c,  is  just  an  abbreviation  of 
Ctor  (i,  I). 


Inductive  /  :  Kind  :=Ci  :  [I/j]n  1 
|  C2  :  [//j]ft 2 

Cn  :  [I/j\nn 

Xqc  provides  two  iterators  to  support  primitive  recursion  on  inductive  kinds.  The  small  elimi¬ 
nation  Elim  [ft7,  ft](r,){r}  takes  a  type  term  r'  of  inductive  kind  ft',  performs  the  iterative  operation 
specified  by  t  (which  contains  a  branch  for  each  constructor  of  ft'),  and  returns  a  type  term  of  kind 
k[t']  as  the  result.  The  large  elimination  Elim/:'.  v](t){k  \  takes  a  type  term  r  of  inductive  kind 
ft',  performs  the  iterative  operation  specified  by  ft,  and  returns  a  kind  term  of  kind  schema  u  as  the 
result.  These  iterators  generalize  the  Typerec  operator  defined  in  Chapter  3. 

Figure  5.3  gives  a  few  examples  of  inductive  definitions  including  the  inductive  kinds  Bool 
and  Nat  and  several  type-level  functions  which  we  will  use  in  Section  5.5.  The  small  elimination 
for  Nat  takes  the  following  form  Elim  [Nat,  ft](r'){ri;  r2  }.  Here,  ft  is  a  dependent  kind  with  kind 
schema  Nat  — >  Kind;  r'  is  the  argument  which  has  kind  Nat.  The  term  in  the  zero  branch,  n, 
has  kind  ft[r'].  The  term  in  the  SUCC  branch,  r2,  has  kind  Nat  — >  ft[r']  — >  k[t'].  We  denote  the 
iterator  operation  in  X'(;(:  as  the  /-reduction.  For  example,  the  two  /.-reduction  rules  for  Nat  work 
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Inductive  Bool  :  Kind  :=  true  :  Bool 

|  false  :  Bool 

Inductive  Nat  :  Kind  :=  zero  :  Nat 

|  succ  :  Nat— > Nat 

plus  :  Nat^Nat-^Nat 

plus(zero)  =  Aa:Nat.a 

plus(succ  a)  =  X a' :  Nat.  SUCC  ((plus  a)  a') 

ifez  :  Nat— ►  (II/: Kind,  j— s-(Nat^j)^j) 

ifez(zero)  =  Xj :  Kind.  Aai  :j.  Aa2:  Nat  —*■_/.  an 
ifez  (SUCC  a)  =  Aj:Kind.  Xai:j.  Aa2:Nat— >j.  a2  a 

le  :  Nat— + Nat — ► Bool 

le(zero)  =  Aa:  Nat.  true 

le(succ  a)  =  Xa' :  Nat.  ifez  a'  Bool  false  (le  a) 

It :  Nat— > Nat  — > Bool 
It  =  Aa:Nat.  le  (SUCC  a) 

Cond  :  Bool  — >  Kind  — >  Kind  — >  Kind 

Cond(true)  =  Aji:  Kind.  Xj2:  Kind,  ji 
Cond(false)  =  Aji:  Kind.  Xj2:  Kind.  j2 

Figure  5.3:  Examples  of  inductive  definitions 


as  follows: 

Elim[Nat,  K](zero){ri;r2}^  n 
Elim[Nat,  k](succ  t2  t  (Elim[Nat,  k](t){ti;  t2}) 

In  Figure  5.3,  plus  is  a  function  which  calculates  the  sum  of  two  natural  numbers.  The  function 
ifez  behaves  like  a  switch  statement:  if  its  argument  is  zero,  it  returns  a  function  that  selects  the 
first  branch;  otherwise,  the  result  takes  the  second  branch  and  applies  it  to  the  predecessor  of  the 
argument.  The  function  le  evaluates  to  true  if  its  first  argument  is  less  than  or  equal  to  the  second. 
The  function  It  performs  the  less-than  comparison. 

The  definition  of  function  Cond,  which  implements  a  conditional  with  result  at  the  kind  level, 
uses  large  elimination  on  Bool.  It  has  the  form  Elim[Bool,  u]  (r)  {ki  ;  k2},  where  r  is  of  kind  Bool; 
both  the  true  and  false  branches  ( n  i  and  k2)  have  kind  schema  u. 
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5.4  Formalization  of  \lcc 

In  this  section,  we  formalize  our  type  language.  It  is  easier  to  do  this  in  terms  of  a  PTS  specification 
(Section  2.5).  Notice  from  Figure  5.2  that  all  the  three  layers  in  our  type  language  essentially 
consist  only  of  abstractions,  applications,  and  constructs  related  to  inductive  definitions.  A  PTS 
specification  allows  us  to  factor  out  this  commonality. 

The  syntax  for  the  PTS  pseudoterms  is: 


( ctxt ) 

A 

::=  •  |  A,X:A 

(sort) 

s  : 

::=  Kind  Kscm  Ext 

(■ var ) 

X  : 

Q 

II 

( ptm ) 

A,  B  : 

::=  s  |  A  |  XX:A.B  \AB\  UX:A.B  \  lnd(A :  Kind){A} 

|  Ctor(i,A)  |  Elim [A! ,  B'](A){B} 

In  addition  to  the  symbols  defined  in  the  syntax,  we  will  also  use  C  to  denote  general  terms, 
Y  and  Z  for  variables,  and  I  for  inductive  definitions.  We  use  A  to  denote  a  sequence  of  terms 
Ai,. . .,  An.  Also,  we  distinguish  between  A  and  A  since  every  element  in  A  would  be  referred  as 
Ai  anyway. 

\lcc  has  the  following  PTS  specification  which  will  be  used  to  derive  its  typing  rules: 

S  =  Kind,  Kscm,  Ext 

A  -  Kind:  Kscm,  Kscm:  Ext 

1Z  =  (Kind,  Kind),  (Kscm,  Kind),  (Ext,  Kind) 

(Kind,  Kscm),  (Kscm,  Kscm) 

In  order  to  ensure  that  the  interpretation  of  inductive  definitions  remains  consistent,  and  they 
can  be  interpreted  as  terms  closed  under  their  introduction  rules,  we  impose  positivity  constraints 
on  the  constructors  of  an  inductive  definition.  The  positivity  constraints  arc  defined  in  Defini¬ 
tion  5.4.1  and  5.4.2. 

Definition  5.4.1  A  term  A  is  strictly  positive  in  X  if  A  is  either  X  or  111"  :  B.  A',  where  A!  is 
strictly  positive  in  X,  X  does  not  occur  free  in  B,  and  X  f  Y. 

Definition  5.4.2  A  term  C  is  a  well-formed  constructor  kind  for  X  (written  wfcx(C) )  if  it  has  one 
of  the  following  forms: 
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1.  X; 


2.  nr :  B.  C1,  where  Y  f  X,  X  is  not  free  in  B,  and  C"  is  a  well-formed  constructor  kind  for 
X;  or 

3.  A—+C',  where  A  is  strictly  positive  in  X  and  C'  is  a  well-formed  constructor  kind  for  X. 

Note  that  in  the  definition  of  wfcx(C),  the  second  clause  covers  the  case  where  C  is  of  the  form 
A  — >  6",  and  X  does  not  occur  free  in  A.  Therefore,  we  only  allow  the  occurrence  of  X  in  the 
non-dependent  case. 

We  often  write  the  well-formed  constructor  kind  for  X  as  nr  :  B.  X.  We  also  denote  terms 
that  are  strictly  positive  in  X  by  nr :  B.  X,  where  X  is  not  free  in  B. 

Definition  5.4.3  Let  C  be  a  well-formed  constructor  kind  for  X.  Then  C  is  of  the  form  nr :  A.  X. 
If  all  the  Y’s  are  a’s,  that  is,  C  is  of  the  form  Ha :  A.  X,  then  we  say  that  C  is  a  small  constructor 
kind  (or  just  small  constructor  when  there  is  no  ambiguity)  and  denote  it  as  small (C). 

Our  inductive  definitions  reside  in  Kind,  whereas  a  small  constructor  does  not  make  universal 
quantification  over  objects  of  type  Kind.  Therefore,  an  inductive  definition  with  small  constructors 
is  a  predicative  definition.  While  dealing  with  impredicative  inductive  definitions,  we  must  forbid 
projections  on  universes  equal  to  or  bigger  than  the  one  inhabited  by  the  definition.  In  particular, 
we  restrict  large  elimination  to  inductive  definitions  with  only  small  constructors. 

Next,  we  define  the  set  of  reductions  on  our  terms.  The  definition  of  f3-  and  77-reduction  is 
standard.  The  /-reduction  defines  primitive  recursion  over  inductive  objects. 

Definition  5.4.4  Let  C  be  a  well-formed  constructor  kind  for  X  and  let  A',  B' ,  and  I  be  pseu¬ 
doterms.  We  define  ^ x,l ,R'{C,  A')  recursively  based  on  the  structure  ofC: 


$x,i,B'(X,  A') 


<S>x,i,b>(RY-.B.C',A') 


$Y,/,B'((n  Y:B.X)^C',A') 


def  A, 

=  A  Y:B.$XiIiB'(C',A'Y) 

=  \Z:(HY :  B.  ,  A'  Z  ( XY-.B.B '  (Z  Y))) 
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Definition  5.4.5  The  reduction  relations  on  our  terms  are  defined  as: 


(XX-.A.B)A'  [A'/X\B 

A  X:A.{BX)  B,  ifX^FV{B) 

Elim[J,  A"](Ctor(i,/)  A){B}  ^  ($X)J ,B>{C»Bi))  A 

I  =  lnd(X:Kind){C} 

where 

B’  =Ay:J.(Elim[/,A/,](y){S}) 

By  >g,  [>r),  and  \>,  we  denote  the  relations  that  correspond  to  the  rewriting  of  subterms  using  the 
relations  and  respectively.  We  use  and  [>  for  the  unions  of  the  above  relations.  We 

also  write  [>*  and  D>+  (respectively  \>*g  etc.)  for  the  reflexive-transitive  and  transitive  closures  of 
t>  (respectively  \>g  etc.)  and  =gr ?t  for  the  reflexive-symmetric-transitive  closure  of  [>.  We  say  that 
a  sequence  of  terms  A\,. .  .,An,  such  that  A  >  A\  >  A2  ■ . .  >  An,  is  a  chain  of  reductions  starting 
from  A. 

Let  us  examine  the  /-reduction  in  detail.  In  Elim[/,  A"]  (A){5},  the  term  A  of  type  I  is  being 
analyzed.  The  sequence  B  contains  the  set  of  branches  for  Elim,  one  for  each  constructor  of  I.  In 
the  case  when  Ci  =  X,  which  implies  that  A  is  of  the  form  Ctor  (i.  I),  the  Elim  just  selects  the  B, 
branch: 

Elim[/,  A"] (Ctor  ((,/)){£}  Bt 

In  the  case  when  Ci  =  BY :  B.X  where  X  does  not  occur  free  in  B,  then  A  must  be  in  the  form 
Ctor  (i.  I )  A  with  A,  of  type  B,  .  None  of  the  arguments  arc  recursive.  Therefore,  the  Elim  should 
just  select  the  /i,  branch  and  pass  the  constructor  arguments  to  it.  Accordingly,  the  reduction  yields 
(by  expanding  the  <[>  macro): 

Elim[/,A"](Ctor(i,J)  A){B}  B%  A 

The  recursive  case  is  the  most  interesting.  For  simplicity  assume  that  the  i-th  constructor  has  the 
form  BY  :  B’ .  X  — r  BY’  :  B" .  X.  Therefore,  A  is  of  the  form  Ctor  (i.  I)  A  with  A\  being  the 
recursive  component  of  type  BY  :  B'.X,  and  .4 9  . . .  An  being  non-recursive.  The  reduction  rule 
then  yields: 

Elim  [I,  A"]  (Ctor  (i,I)  A){B}  ^  B{  A,  (XY  :B'.  Elim[/,  A"](A\  r){B})  A2...An 
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The  Elim  construct  selects  the  11,  branch  and  passes  the  arguments  A\.. . An,  and  the  result  of 
recursively  processing  A\.  In  the  general  case,  it  would  process  each  recursive  argument. 

Definition  5.4.6  defines  the  T  macro  which  represents  the  type  of  the  large  Elim  branches. 
Definition  5.4.7  defines  the  £  macro  which  represents  the  type  of  the  small  elimination  branches. 
The  different  cases  follow  from  the  /-reduction  rule  in  Definition  5.4.5. 

Definition  5.4.6  Let  C  be  a  well-fonned  constructor  kind  for  X  and  let  A'  and  I  be  two  terms.  We 
define  T x.i( C,  ,4')  recursively  based  on  the  structure  of  C: 

*xAx’A')  =  A' 

yx,i(nY:B.C',A')  d=  UY:B.^x,i(C',A') 

*xAa^C',A')  dAf  [I/X\A^[A'/X\A^*Xii(C',A') 

where  X  is  not  free  in  B  and  A  is  strictly  positive  in  X. 

Definition  5.4.7  Let  C  be  a  well-formed  constructor  kind  for  X  and  let  A',  I,  and  B'  be  terms. 
We  define  (x,l(C,  A' .  If  )  recursively  based  on  the  structure  ofC: 

(x,i(x,  a',B')  =f  A'  B' 

Cx,/(nF :  B.  C',  A',  B')  ='  IIF :  B.  (x,i{C',  A',  B’  Y) 

(x,i(nY:B.X  -»•  C',A',B')  d=  UZ  :(UY :  B.  I).UY :  B.  (A'  (Z  Y))  —  (x,i(C' ,  A' ,  B'  Z ) 
where  X  is  not  free  in  B  and  B. 

Definition  5.4.8  We  use  A|„j  to  denote  that  the  environment  does  not  contain  any  z  variables. 

Here  arc  the  complete  typing  rules  for  Xqq.  The  three  weakening  rules  make  sure  that  all  variables 
arc  bound  to  the  right  classes  of  terms  in  the  context.  There  arc  no  separate  context-formation 
rules;  a  context  A  is  well-formed  if  we  can  derive  the  judgment  A  E  Kind  :  Kscm  (notice  we  can 
only  add  new  variables  to  the  context  via  the  weakening  rules). 


•  1-  Kind  :  Kscm 

(AXl) 

•  h  Kscm  :  Ext 

(ax2) 

Ah  C:  Kind  A  1 -  A:  B  Dom(  A) 

A ,a:C  h  A:  B 

(WEAKl) 
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A  h  C  :  Kscm  Ah  A:  B  j  Dom{  A) 
A,j:C  h  A:B 

A  h  C:  Ext  A  \~  A:  B  z  $  Dom{  A) 

A ,z:C  h  A  :  B 

A  h  Kind  :  Kscm  X  e  Dom(A) 

A  h  A  :  A(A) 

A,X:AhB:B'  Ahn  X:A.B':s 

A  h  XX:  A.  B  :  HX-.A.B' 

A  h  A  :  nX:B'.  A'  Ah  B  :  B' 

A  h  A  B  :  [B/X\A' 

A  h  A  :  si  A,  X :  A  h  B  :  S2  (si,  s 2)  £  X 


for  all  i 


A  h  UX :  A.  B  :  s2 

A,  A: Kind  h  Ci :  Kind 


wfcx{Ci) 


A  h  lnd(A :  Kind){C'}  :  Kind 

Ah  I  :  Kind  where  I  =  lnd(A :  Kind){C} 
A  h  Ctor  (i,  I)  :  [I/X]Ci 

Ah  A:  I  Ah  A'  :  I  ^  Kind 

for  all  i  A  \~  Bi  :  A' ,  Ctor  (i,  If) 

A  h  Elim [I,A'](A){B}  :  A'  A 
where  I  =  lnd(A :  Kind){C} 


(weak2) 

(weak3) 

(var) 

(FUN) 

(APP) 

(PROD) 

(IND) 

(CON) 


(ELIM) 


Ah  A:  I  A\aj  h  A!  :  Kscm 
for  all  i  small(Ci )  Ah  Bi  :  'h  x,i(Ci,  A') 

A  h  B\m[I,A'](A){B}  :  A' 
where  I  =  lnd(A :  Kind){C} 


(L-ELIM) 


Ah  A:  B  Ah  B'  :s  Ah  B  : 


B  B'  (CONY) 


A  h  A  :  B' 

We  will  merely  state  Xqq’s  meta-theoretic  properties  here  and  defer  the  proofs  to  Appendix  C. 


Theorem  5.4.9  Reductions  of  well-fanned  terms  is  strongly  normalizing  and  confluent. 

We  will  next  show  a  sample  computation  language  and  show  how  the  expressivity  of  the  type 
language  may  be  put  to  use. 
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(exp)  e  ::=  x  \  n  |  tt  |  ff  |  /  |  fix  x:A.  f  \  e  e!  \  e[A]  \  (X  =  A,  e:A') 

|  open  e  as  ( X ,  x)  in  e!  \  (e0,  . . .  en_i)  |  sel[A](e,  e!)  \  e  aop  e! 
|  ecope'  |  if[v4, ^4'](e,  X\.e\,  X2.e2) 

where  n  G  N 

(fun)  f  ::=  Xx:A.  e  \  AX  :  A.  f 

(i arith )  aop  ::=  +  |  . . . 

(cmp)  cop  ::=  <  |  . . . 


Figure  5.4:  Syntax  of  the  computation  language  A h- 


5.5  The  computation  language  A// 

The  language  of  computations  A h  can  use  proofs  and  propositions  (constructed  in  the  type  lan¬ 
guage)  to  represent  program  invariants  expressible  in  higher-order  predicate  logic.  This  allows  us 
to  assign  a  more  refined  type  to  programs  when  compared  to  other  higher-order  typed  calculi. 

In  this  section  we  often  use  the  unqualified  “term”  to  refer  to  a  computation  term  (expression) 
e,  with  syntax  defined  in  Figure  5.4.  Most  of  the  constructs  arc  borrowed  from  standard  higher- 
order  typed  calculi.  We  will  only  consider  constants  representing  natural  numbers  (n  is  the  value 
representing  n  €  N)  and  boolean  values  (tt  and  ff).  The  term-level  abstraction  and  application  arc 
standard;  type  abstractions  and  fixed  points  arc  restricted  to  function  values  since  we  use  call-by- 
value  semantics.  The  type  variable  bound  by  a  type  abstraction,  as  well  as  the  one  bound  by  the 
open  construct  for  packages  of  existential  type,  can  have  either  a  kind  or  a  kind  schema.  Dually, 
the  type  argument  in  a  type  application,  and  the  witness  type  term  A  in  the  package  construction 
(X  =  A,  e:  A')  can  be  either  a  type  term  or  a  kind  term. 

The  constructs  implementing  tuple  operations,  arithmetic,  and  comparisons  have  nonstandard 
static  semantics,  on  which  we  focus  in  section  5.5.1,  but  their  runtime  behavior  is  standard.  The 
branching  construct  is  parameterized  at  the  type  level  with  a  proposition  (which  is  dependent  on 
the  value  of  the  test  term)  and  its  proof;  the  proof  is  passed  to  the  executed  branch. 

Dynamic  semantics  We  present  a  small  step  call-by-value  operational  semantics  for  Xh  in  the 
style  of  Wright  and  Felleisen  [WC94],  The  values  arc  defined  as  shown  below.  The  reduction 
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(Xx:A.e)v  ^  [v/x\e 

(R-/3) 

(A X:B.f)[A]  ^  [A/X]f 

(R-TY-/3) 

sel[A]((n0,  . . .  vn-i ),m)  vm  (m  <  n) 

(R-SEL) 

open  (X'  =  A,  v.A’)  as  {X,  x)  in  e 
^  [v/x\[A/X\e 

(R-open) 

(fi \Xx:A.f)v  ^  ([fix  x\ A.  f/x\f)  v 

(R-fix) 

(fix  x:A.  f)[A']  ([fix  x:A.  f/x\f)[A'] 

(R-tyfix) 

m  +  n  m  +  n 

(R-add) 

m<n  tt  (m  <  n) 

(R-lt-T) 

m<n  ff  (m  >  n) 

(R-lt-F) 

if[H,A](tt,  X1.e1,X2.e2)  [A/Xfa 

(R-if-T) 

if[B,A](ff,  Ai.ei,  X2.e2)  [A/X2}e2 

(R-if-F) 

Figure  5.5:  Dynamic  semantics 

relation  is  specified  in  Figure  5.5. 

v  ::=  n  |  tt  |  ff  |  /  |  fix  x:A.  f  \  (. X  =  A ,  v:A')\  (v0,  . . .  nn_i) 


An  evaluation  context  E  encodes  the  call-by- value  discipline: 

E  ::=  •  |  E  e  \  v  E  \  E[A }  \  (X  =  A,  E:A')  |  open  E  as  ( X ,  x)  in  e 

|  open  V  as  (X,  x)  in  E  \  (v0,  E,  ei+2 ,  •  •  • ,  en_i)  |  sel[A](f;, e) 

|  sel[A](n,  E)  |  E  aop  e  \  v  aop  E  \  E  cop  e  \  v  cop  E 

\\f[A,A'](E,  Xi.eu  X2.e2) 

The  notation  E{e}  stands  for  the  term  obtained  by  replacing  the  hole  •  in  E  by  e.  The  single  step 
computation  i— >  relates  E{e}  to  E{e'}  when  e  e',  and  i— is  its  reflexive  transitive  closure. 

As  shown  the  semantics  is  standard  except  for  some  additional  passing  of  type  terms  in  R-SEL 
and  R-if-T/F.  However  an  inspection  of  the  rules  shows  that  types  arc  irrelevant  for  the  evaluation, 
hence  a  type-erasure  semantics,  in  which  all  type -related  operations  and  parameters  arc  erased, 
would  be  entirely  standard. 
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5.5.1  Static  semantics 


The  static  semantics  of  A h  shows  the  benefits  of  using  a  type  language  as  expressive  as  X'cr.  We 
can  now  define  the  type  constructors  of  A h  as  constructors  of  an  inductive  kind  17,  instead  of  having 
them  built  into  A h- 


Inductive  17  :  Kind  :=  snat  :  Nat— >0 
|  sbool  :  Bool^l7 

|  — »  :  17— >17^17 

|x  :  Nat— >  (Nat  ^17) —>  17 
I  VKind  :  IIj  :  Kind,  (j— >17)— >17 
|  3Kind  :  Ilj :  Kind,  (j  — >  17)  — >  17 
|  VKscm  :  Hz :  Kscm .  (z  — >  17)  — >  17 
I  3 Kscm  :  Bz:  Kscm.  (z  — >17)  — >17 

Informally,  all  well-formed  computations  have  types  of  kind  17,  including  singleton  types  of  nat¬ 
ural  numbers  snat  A  and  boolean  values  sbool  B,  as  well  as  function,  tuple,  polymorphic  and 
existential  types.  To  improve  readability  we  also  define  the  syntactic  sugar 

B  =  -»  AB 

\/sX:A.B  =  ys  A  (XX-.A.B)  } 

>  where  .s  G  {Kind,  Kscm} 

3SX:A.B  =  3S  A  (XX:A.B)  J 

and  often  drop  the  sort  s  when  s  =  Kind;  e.g.  the  type  void,  containing  no  values,  is  defined  as 
Va:!7.  a  =  V|^jnc|  17  (Aa:17.  a). 

Using  this  syntactic  sugar  we  can  give  a  familial-  look  to  many  of  the  formation  rules  for  A  u 
expressions  and  functional  values.  Figure  5.6  contains  the  inference  rules  for  deriving  judgments 
of  the  form  A;  T  b  e  :  ,4,  which  assign  type  A  to  the  expression  e  in  a  context  A  and  a  type 
environment  T  defined  by 

(i type  env)  T  ::=  •  |  T,a;:  A 

We  introduce  some  of  the  notation  used  in  these  rules  in  the  course  of  the  discussion. 

Rules  E-nat,  E-true,  and  E-FALSE  assign  singleton  types  to  numeric  and  boolean  constants. 
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A  I-  Kind  :  Kscm 

Ah  -  ok 

Ah  T  ok  A  h  i:n 
A  h  T,x:A  ok 


(TE-mt) 

(TE-add) 


A  h  r  ok 
A;  r  h  x  :  r(x) 

A  h  r  ok 
A;  T  h  n  :  snat  n 


(E-var) 

(E-nat) 


A  h  r  ok 

A;  T  h  tt :  sbool  true 


(E-true) 


A  h  T  ok 

A;  r  h  ff :  sbool  false 


(E-false) 


A  h  A  :  Q  A;  r,x:A  h  f  :  A 
A;  T  h  fix  x:A.f  :  A 

A  h  A  :  Q  A;  T,x:A  he:i' 
A;  T  h  \x:A.e:  A  -►  A' 

A;  T  h  ei  :  A  ->■  A'  A;  V  h  e2  :  A 
A;  T  h  e1e2  ■■  A' 


Ah  B:s  A  ,X:B;  T  h  /  :  A 


A 

;  r  h  A  A : 

B.f  :  \/sX :  B.  A 

i 

A;  T 

h  e  :  \/sX 

:B.  A!  A  h  A  : 

:  B 

A;  T  h  ( 

M  :  [A/ X\  A' 

Ah  A:  B  Ah  B  :  s 

A;  T  h 

■  e  :  [A/X\A' 

aT 

r  h  (X  =  A,  e\A!)  :  3SX:B 

i7 

A;  T 

h  e  :  3SX' 

:  B.  A  A  h  A'  : 

n 

A, 

X:B ;  T,x : 

[X/X']A  h  e'  :  A! 

A;  r  h  open  e  as  (X,  x)  in  e'  :  A' 


s  ^4  Ext  J 
(s  /  Ext) 


(s  +  Ext) 


(X£A\ 
Vs  +  ExV 


A;  r  h  e  :  snat  A  A;  F  h  e!  :  snat  A' 
A;  T  h  e  +  e!  :  snat  (plus  A  A') 


A;  T  h  e  :  snat  A  A;  T  h  e!  :  snat  A' 
A;  T  h  e  <  e!  :  sbool  (It  A  A') 


(E-fix) 

(E-fun) 

(E-app) 

(E-tfun) 

(E-tapp) 

(E-pack) 

(E-open) 

(E-add) 

(E-lt) 


Figure  5.6:  Static  semantics  of  the  computation  language  A h 
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(E-tup) 


for  all  i  <  n  A;  T  h  e*  :  Ai 
A;  T  h  (e0,  . . .  en_i) 

:  x  n  (nth  (A0\\...  ::^n_i::nil)) 

A;  T  h  e  :  x  A"  B  A;  T  h  e'  :  snat  A' 

A  h  H  :  LT  A'  A" 

A;  T  h  sel[A](e,e')  :  B  A' 

Ah  B  :  Bool— +  Kind  A;  r  h  e  :  sbool  A " 

Ah  A:  BA”  A,  Xx:B  true;  T  h  ei  :  A' 

A  h  A'  :  Q  A,  X2:B  false;  T  h  e2  :  A' 

A;  T  h  if [B,A]{e,  Ai.ei,  X2.e2)  :  A' 

A;  T  h  e  :  A  A  =  v  A'  A  h  A'  :  O 
A;  T  h  e  :  A' 


(E-sel) 


(E-if) 


(E-conv) 


Figure  5.6:  Static  semantics  of  the  computation  language  A  //(contd.) 


For  instance  the  constant  1  has  type  snat  (SUCC  zero)  in  any  valid  environment.  In  rule  E-NAT  we 
use  the  meta-function  '  to  map  natural  numbers  n  €  N  to  their  representations  as  type  terms.  It  is 
defined  inductively  by  0  =  zero  and  n+1  =  SUCC  n,  so  A  h  n  :  Nat  holds  for  all  valid  A  and 
n  G  N. 

Singleton  types  play  a  central  role  in  reflecting  properties  of  values  in  the  type  language,  where 
we  can  reason  about  them  constructively.  For  instance  rules  E-ADD  and  E-LT  use  respectively  the 
type  terms  plus  and  It  (defined  in  Section  5.3)  to  reflect  the  semantics  of  the  term  operations  into 
the  type  level  via  singleton  types. 

However,  if  we  could  only  assign  singleton  types  to  computation  terms,  in  a  decidable  type 
system  we  would  only  be  able  to  typecheck  terminating  programs.  We  regain  expressiveness  of 
the  computation  language  using  existential  types  to  hide  some  of  the  too  detailed  type  information. 
Thus  for  example  one  can  define  the  usual  types  of  all  natural  numbers  and  boolean  values  as 

nat  :  Q  =  3a:  Nat.  snat  a 
bool  :  n  =  3a:  Bool,  sbool  a 

For  any  term  e  with  singleton  type  snat  A  the  package  (a  =  A,  e  :  snat  a)  has  type  nat.  Since 
in  a  type-erasure  semantics  of  A  u  all  types  and  operations  on  them  are  erased,  there  is  no  runtime 
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overhead  for  the  packaging.  For  each  n  €  N  there  is  a  value  of  this  type  denoted  by  n  =  (a  = 
n,  n :  snat  a).  Operations  on  terms  of  type  nat  arc  derived  from  operations  on  terms  of  singleton 
types  of  the  form  snat  A;  for  example  an  addition  function  of  type  nat  — >  nat  — >  nat  is  defined  as 
the  expression 

add  =  Axiinat.  Ax2:nat. 

open  Xi  as  (an,  xj)  in  open  x2  as  (a2,  x2)  in 
(a  =  plus  ai  a2,  x[  +  x2:snat  a) 

Rule  E-tup  assigns  to  a  tuple  a  type  of  the  form  x  A  B,  in  which  the  x  constructor  is  applied 
to  a  type  A  representing  the  tuple  size,  and  a  function  B  mapping  offsets  to  the  types  of  the  tuple 
components.  This  function  is  defined  in  terms  of  operations  on  lists  of  types: 

Inductive  List  :  Kind  :=  nil  :  List 

I  cons  :  17— >  List-*  List 


nth  :  List— >Nat— >17 

nth  nil  =Aa: Nat.  void 

nth  (cons  a\  a2)  =  Aa:Nat.  ifez  a  17  a±  (nth  a2) 

Thus  nth  L  ri  reduces  to  the  n-th  element  of  the  list  L  when  n  is  less  than  the  length  of  L,  and 
to  void  otherwise.  We  also  use  the  infix  form  Av.A!  =  cons  A  A! .  The  type  of  pairs  is  derived: 
A  x  A'  =  x  2  (nth  (y4::^4'::nil)).  Thus  for  instance  F  (42,7)  :  snat  42  x  snat  7  is  a  valid 
judgment. 

The  rules  for  selection  and  testing  for  the  less-than  relation  refer  to  the  kind  term  LT  with 
kind  schema  Nat  — >  Nat  — >  Kind.  Intuitively,  LT  represents  a  binary  relation  on  kind  Nat,  so 
LT  m  n  is  the  kind  of  type  terms  representing  proofs  of  m  <  n.  LT  can  be  thought  of  as  the 
parameterized  inductive  kind  of  proofs  constructed  from  instances  of  the  axioms  Vn  6  N .  0  <  n+1 

and  Vm,  n  G  N.  m  <  n  D  m+ 1  <  n+1: 

Inductive  LT  :  Nat— > Nat— >  Kind 
:=  Itzs  :  Ila:  Nat.  LT  zero  (succ  a) 

|  ItSS  :  Ila :  Nat.  Fla' :  Nat.  LT  a  a’  ->  LT  (SUCC  a)  (SUCC  a’) 

In  our  type  language  we  allow  inductive  kinds  of  kind  scheme  Kind  only.  Thus  we  actually  need 
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to  use  a  Church  encoding  of  LT  (see  [SSTP01]  for  the  encoding). 

In  the  component  selection  construct  sel[A](e,  e')  the  type  A  represents  a  proof  that  the  value 
of  the  subscript  e'  is  less  than  the  size  of  the  tuple  e.  In  rule  E-SEL  this  condition  is  expressed  as  an 
application  of  the  type  term  LT.  Due  to  the  consistency  of  the  logic  represented  in  the  type  language, 
only  the  existence  and  not  the  structure  of  the  proof  object  A  is  important.  Since  its  existence  is 
ensured  statically  in  a  well-formed  expression,  A  would  be  eliminated  in  a  type-erasure  semantics. 

The  branching  construct  if [B,  A](e,  X\.  ei,  X2.  e2)  takes  a  type  term  A  representing  a  proof 
of  the  proposition  encoded  as  either  B  true  or  B  false,  depending  on  the  value  of  e.  The  proof 
is  passed  to  the  appropriate  branch  in  its  bound  type  variable  (X  \  or  X2).  The  correspondence 
between  the  value  of  e  and  the  kind  of  A  is  again  established  through  a  singleton  type. 

5.5.2  Example:  bound  check  elimination 

A  simple  example  of  the  generation,  propagation,  and  use  of  proofs  in  A  /y  is  a  function  which 
computes  the  sum  of  the  components  of  any  vector  of  naturals.  Let  us  first  introduce  some  auxiliary 
types  and  functions.  The  type  assigned  to  a  homogeneous  tuple  (vector)  of  n  terms  of  type  A  is 
(3rjL -convertible  to  the  form  vec  n  A  for 

vec  :  Nat— rD— 

vec  =  Aa :  Nat.  A a  (nth  (repeat  a  «')) 

where 

repeat  :  Nat  List 

repeat  zero  =  Ac/:fInil 

repeat  (succ  a)  =  Ac/ :fl.  c/::  (repeat  a )  a' 
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Then  we  can  define  a  term  which  sums  the  elements  of  a  vector  with  a  given  length  as  follows: 


sumVec :  Va :  Nat.  snat  a  — >  vec  a  nat  — ►  nat 
=  Acc :  Nat.  An :  snat  a.  Av :  vec  a  nat. 

(fix  loop: nat  — ■>  nat  — *  nat. 

Ai:nat.  Asum:nat. 
open  i  as  («',  i7)  in 
if[LTOrTrue  a'  a,  ItPrf  a'  a] 

(i'<n, 

a\.  loop  (add  i  1)  (add  sum  (sel[«i](v,  i7))), 

«2  .sum))  0  0 

where 

LTOrTrue  :  Nat— >  Nat— >  Bool— >  Kind 

LTOrTrue  =  Am :  Nat.  Am  :Nat.  Aa:  Bool.  Cond  a  (LT a\  02)  True 

The  comparison  i7<n,  used  in  this  example  as  a  loop  termination  test,  checks  whether  the 
index  i7  is  smaller  than  the  vector  size  n .  If  it  is,  the  adequacy  of  the  type  term  It  with  respect  to 
the  less-than  relation  ensures  that  the  type  term  ItPrf  a'  a  represents  a  proof  of  the  corresponding 
proposition  at  the  type  level,  namely  LT  a'  a.  This  proof  is  then  bound  to  a  1  in  the  first  branch  of 
the  if,  and  the  sel  construct  uses  it  to  verify  that  the  i7-th  element  of  V  exists,  thus  avoiding  a  second 
test.  The  type  safety  of  A h  (Theorem  5.5.1)  guarantees  that  implementations  of  sel  need  not  check 
the  subscript  at  runtime.  Since  the  proof  a 2  is  ignored  in  the  “else”  branch,  ItPrf  a'  a  is  defined  to 
reduce  to  the  trivial  proof  of  True  when  the  value  of  i7  is  not  less  than  that  of  n. 

As  an  aside,  the  usual  vector  type,  which  keeps  the  length  packaged  with  the  content,  is  then: 

vector  :  Q  — >  Q  =  Aa :  Q.  3cr7 :  Nat.  snat  a'  x  vec  a'  a. 

We  won’t  give  here  the  proof  of  type-safety  for  this  sample  computation  language  A h-  The 
interested  reader  may  refer  to  [SSTP01]  for  the  details.  The  proof  does  not  contain  any  new  sub¬ 
tleties. 

Theorem  5.5.1  (Safety  of  A h)  If  P  e  :  A,  then  either  e  is  a  value  or  there  exists  an  e'  such  that 
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e  i— >  e'  and  e'  :  A. 


5.6  Summary  and  related  work 

To  sum  up,  an  intermediate  language  is  now  constructed  by  combining  our  type  language  \lcc 
with  a  particular  computation  language.  The  type  system  for  the  particular  computation  language 
is  created  by  giving  the  inductive  definition  for  the  base  kind  Q.  For  example,  the  computation 
language  here  was  A h  with  the  base  kind  defined  at  the  beginning  of  Section  5.5.1. 

Our  type  language  is  a  valiant  of  the  calculus  of  constructions  [CH88]  extended  with  inductive 
definitions  (with  both  small  and  large  elimination)  [Pau93,  Wer94],  We  support  77-reduction  in 
our  language  while  the  official  Coq  system  does  not.  The  proofs  for  the  properties  of  \lcc  are 
adapted  from  Geuvers  [Geu93]  and  Werner  [Wer94] ;  the  main  difference  is  that  our  language  has 
kind-schema  variables  and  a  new  product  formation  rule  (Ext.  Kind)  which  are  not  in  Werner’s 
system. 

The  Coq  proof  assistant  provides  support  for  extracting  programs  from  proofs  [Pau93].  It 
separates  propositions  and  sets  into  two  distinct  universes  Prop  and  Set.  We  do  not  distinguish 
between  them  because  we  are  not  aiming  to  extract  programs  from  our  proofs,  instead,  we  are  using 
proofs  as  specifications  for  our  computation  terms. 

Xi  and  Pfenning’s  DML  [XP99]  is  the  first  language  that  nicely  combines  dependent  types  with 
programs  that  may  involve  effects.  Our  ideas  of  using  singleton  types  and  lifting  the  level  of  the 
proof  language  are  directly  inspired  by  their  work.  Xi’s  system,  however,  does  not  support  arbitrary 
propositions  and  explicit  proofs.  It  also  does  not  define  the  O  kind  as  an  inductive  definition  so  it  is 
unclear  how  it  interacts  with  intensional  type  analysis  [TSSOO]  and  how  it  preserves  proofs  during 
compilation. 

We  have  discussed  the  relationship  between  our  work  and  those  on  PCC,  typed  assembly  lan¬ 
guages,  and  intensional  type  analysis  in  Section  5.1.  Inductive  definitions  subsume  and  general¬ 
ize  earlier  systems  on  intensional  type  analysis  [HM95,  CWM99,  TSSOO];  the  type-analysis  con¬ 
struct  in  the  computation  language  can  be  eliminated  using  the  technique  proposed  by  Crary  et 
al.  [CWM98]. 

Crary  and  Vanderwaart  [CV01]  recently  proposed  a  system  called  LTT  which  also  aims  at 
adding  explicit  proofs  to  typed  intermediate  languages.  LTT  uses  Linear  LF  [CP96]  as  its  proof 
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language.  It  shares  some  similarities  with  our  system  in  that  both  arc  using  singleton  types  [XP99] 
to  circumvent  the  problems  of  dependent  types.  However,  since  LF  does  not  have  inductive  def¬ 
initions  and  the  Elim  construct,  it  is  unclear  how  LTT  can  support  intensional  type  analysis  and 
type-level  primitive  recursive  functions  [CWOO]. 
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Chapter  6 


Implementation 


In  this  chapter  we  discuss  the  implementation  details  of  the  type  system  for  certified  runtime  type 
analysis.  We  implemented  the  type  system  in  an  experimental  version  of  the  Standard  ML  of  New 
Jersey  compiler  [AM91].  The  motivation  for  the  implementation  was  two-fold.  First,  we  wanted 
to  create  an  infrastructure  that  can  be  used  for  writing  certified  applications.  Second  we  wanted 
to  measure  the  overhead  of  implementing  such  an  expressive  type  system  in  an  industrial-strength 
compiler. 

The  current  SML/NJ  compiler  (vl  10.34)  is  a  type-preserving  compiler;  in  fact,  types  arc  prop¬ 
agated  through  all  optimizations  and  right  till  code  generation.  The  intermediate  language  of  the 
compiler  is  based  on  the  predicative  TL  calculus  [Sha97b],  The  type  language,  by  itself,  is  similar 
to  the  simply  typed  lambda  calculus. 

Our  implementation  uses  the  frontend  and  the  code  generator  from  the  existing  compiler.  The 
type  preserving  phase  is  new,  and  uses  the  certifying  type  system  described  in  Chapter  5.  We  im¬ 
plemented  this  system  since  it  integrates  runtime  type  analysis  and  a  logical  system  inside  a  single 
framework.  We  implemented  the  new  type  system  and  the  associated  type  manipulation  opera¬ 
tions,  and  then  re-wrote  all  the  optimizations  to  use  this  new  type  system.  Thus  the  type -preserving 
phases  in  both  the  compilers  arc  the  same:  we  do  inlining,  specialization,  loop  optimizations,  lay 
down  efficient  data  representations,  etc.  Figure  6. 1  illustrates  the  design  of  the  two  compilers. 

We  have  not  used  the  new  type  system  to  prove  safety  properties  of  programs;  however,  the 
implementation  maintains  all  the  information  that  is  needed  to  write  certified  applications.  In  the 
old  implementation  the  base  kind  17  (the  kind  for  the  type  of  terms)  was  an  in-built  primitive  kind. 
As  shown  in  Chapter  5,  the  new  type  system  provides  a  mechanism  for  defining  kinds  inductively. 
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FLINT  =  Computation  language  (CL)  + 
type  language  (TL) 

TL  =  Simply  typed  lambda  calculus 

Figure  6.1:  Comparing  the  implementations 
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Benchmark 

No  of  lines 

Average  type  size 

Type  size  distribution 
>  102  >  103  >  104  >  105 

Mlyacc 

6030 

36 

510  56 

Vliw 

3679 

73 

874  197 

CML 

6152 

81 

1359  34  27 

Figure  6.2:  Size  of  types  generated  during  compilation 


The  base  kind  fl  is  now  an  inductively  defined  kind  (see  Section  6.4);  type  constructors  such  as 
tuples,  vectors,  arrays,  function  types,  etc  arc  members  of  this  inductive  definition.  Furthermore, 
each  of  these  types  carry  more  information.  For  example,  a  tuple  type  not  only  carries  the  type 
of  each  component,  but  also  the  length  of  the  tuple.  Therefore,  the  new  compiler  creates  the 
scaffolding  required  for  certifying  programs;  thus,  we  can  measure  the  overhead  introduced  by  the 
new  type  system. 

How  does  a  type  system  impact  the  compilation  strategy  ?  To  get  an  idea  we  took  some  mea¬ 
surements  of  the  amount  of  type  information  generated  by  the  Standard  ML  of  New  Jersey  compiler 
during  the  compilation  process.  Figure  6.2  shows  the  figures  on  three  large  benchmarks.  Mlyacc  is 
a  parser  generator  for  Standard  ML,  vliw  is  an  instruction  scheduler  for  a  vliw  compiler,  and  CML 
is  an  implementation  of  Concurrent-ML  [Rep91].  The  amount  of  type  information  is  measured  in 
terms  of  the  number  of  nodes  in  a  type.  Essentially,  if  we  consider  a  type  as  a  tree,  then  this  table 
counts  the  number  of  nodes  in  the  tree.  For  example,  a  primitive  type  like  int  is  of  size  one,  a  pair 
int  x  int  is  of  size  two,  a  type  (int  x  int)  — >  int  is  of  size  three,  and  so  on.  The  sizes  are  calculated 
without  taking  any  sharing  (between  types)  into  consideration.  The  third  column  in  Figure  6.2 
shows  the  average  number  of  nodes  in  a  type.  For  example,  during  the  compilation  of  mlyacc  a 
type  on  the  average  has  36  nodes.  The  last  column  shows  the  spread  in  the  size  of  the  types:  during 
the  compilation  of  mlyacc  we  generate  510  types  with  each  of  them  having  more  than  a  hundred 
nodes,  and  56  types  with  each  of  them  having  more  than  a  thousand  nodes. 

This  table  shows  that  the  overhead  incurred  from  a  type  system  is  surprisingly  large.  For 
example,  on  CML  the  compilation  generates  a  good  number  of  types  with  more  than  ten  thousand 
nodes  each.  Since  the  type  system  in  the  compiler  is  similar  to  the  simply  typed  lambda  calculus, 
these  figures  reflect  the  overhead  of  using  the  simplest  system  in  the  lambda-cube.  Therefore,  one 
of  the  key  questions  is:  will  the  type  information  that  must  be  maintained  for  the  most  expressive 
system  (in  the  lambda-cube)  overwhelm  the  compiler  ? 
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6.1  Implementing  a  pure  type  system 


The  implementation,  like  the  formalization,  uses  the  PTS  specification  of  the  type  system.  This 
allows  us  to  use  the  same  datatype  for  types,  kinds,  and  kind  schemas:  therefore,  it  provides  a 
tremendous  economy  in  the  number  of  constructs  that  need  to  be  implemented.  The  datatype 
pterm  used  for  representing  the  PTS  is  shown  below: 
datatype  sort 


datatype 


=  Kind 
Kscm 

|  Ext 

pterm 

=  Var  of  int  *  sort 
Srt  of  sort 
Pi  of  pterm  *  pterm 
Fri  of  pterm  *  pterm 
App  of  pterm  *  pterm 
Ind  of  pterm  *  int  *  pterm  list 
Con  of  pterm  *  int  *  int  *  pterm  list 
Fix  of  int  list  *  pterm  *  int  *  pterm  list 
Case  of  pterm  *  pterm  *  pterm  list 
Seq  of  pterm  list 
Proj  of  pterm  *  int 
Cl  os  of  pterm  *  int  *  int  *  env 


(*  variables  *) 

(*  sorts  *) 

(*  product  *) 

(*  abstraction  *) 

(*  application  *) 

(*  inductive  definition  *) 

(*  constructor  of  inductive  definition  *) 
(*  fixpoint  *) 

(*  case  construct  *) 

(*  record  *) 

(*  projection  *) 

(*  closure  *) 


datatype  env 

=  Ernp 

Sub  of  (int  *  pterm)  *  env 


(*  empty  environment  *) 

(*  environment  with  a  substitution  *) 


We  use  DeBruijn  indices  [De  80]  for  variables.  Thus  a  term  of  the  form 
XX  :  A.  A Y :  X. . . .  Y  . . .  X  . . .  is  represented  as  A_ :  A.  A_:  #1.  . . .  #1 . . .  #2  . . .  where  the  vari¬ 
able  is  denoted  by  its  lexical  depth.  This  is  useful  because  two  a- equivalent  terms  now  have  the 
same  representation.  The  variables  contain  another  bit  of  information.  Since  we  are  using  a  PTS 
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representation,  there  is  no  syntactic  distinction  between  types,  kinds,  and  schemas.  But  for  type¬ 
checking,  this  information  is  often  useful:  the  extra  bit  memoizes  this  information.  Our  binding 
constructs  (Fn  and  Pi  )  now  only  need  to  store  the  type  of  the  bound  variable.  For  example, 
XX  :  A.  B  is  represented  as  Fn(p\,  p-2)  where  p\,P2  are  the  representations  for  A  and  B  respec¬ 
tively. 

The  mechanism  for  inductive  definition  is  more  general  than  that  presented  in  Chapter  5.  The 
implementation  allows  mutually  recursive,  parametrized  inductive  definitions.  The  first  sub-term 
contains  the  body  of  the  inductive  definitions,  the  integer  says  which  definition  we  arc  interested 
in,  and  the  list  at  the  end  represents  the  arguments.  Consider  the  inductive  definitions  shown  below. 
We  first  define  the  natural  numbers  and  then  define  an  integer  list  that  keeps  track  of  its  length.  The 
empty  list  has  zero  length.  When  we  cons  an  integer  to  a  list,  we  increase  its  length  by  one: 
Inductive  (Nat:Kind) 

=  zero  :  Nat 

SUCC  :  Nat  — »  Nat 

Inductive  (ListNat:Nat  — ■>  Kind) 

=  nil  :  ListNat(zero) 

|  cons  :  AX  :Nat.  int  — ■>  ListNat(A)  — ►  ListNat(succ(X)) 

Suppose  that  we  wanted  to  represent  the  inductive  definition  of  ListNat.  The  arrow  type  — > 

should  be  represented  as  a  product  type,  but  we  will  use  the  arrow  type  wherever  possible  to  make 

the  presentation  clearer.  We  first  build  the  pseudoterm  p  representing  the  definition: 

p  =  Fn  ( Seq  [Natpts  — >  Kind I], 

Seq  [ 

Seq[App{# l,zeropts),  Pi( Natpfs,  int  ->  App(# 2,  #1)  —  App(# 2,  succpte(#l))  ] 


) 

An  inductive  definition  binds  a  set  of  names;  we  use  the  Fn  construct  for  this.  As  is  the  case 
with  ordinary  functions,  the  Fn  construct  carries  only  the  type  of  the  bound  variables.  Since 
we  may  have  mutually  inductive  definitions,  we  use  the  Seq  construct  that  lets  us  bind  a  list  of 
variables.  In  the  example  above,  the  inductive  definition  introduces  a  variable  of  type  Nat  — >  Kind; 
therefore,  Fn  binds  a  Seq  |Nat;)/.s  — >  Kind\.  We  use  Natp/..,  to  denote  the  PTS  representation  of  the 
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inductive  definition  Nat.  The  body  of  Fn  contains  the  definition  of  the  constructors.  The  body  is  a 
sequence  where  every  member  contains  the  constructors  (as  a  sequence)  for  one  particular  inductive 
definition.  The  variables  introduced  by  the  definition  (in  this  case  ListNat)  arc  denoted  by  DeBruijn 
indices.  We  use  zeropts  and  succp/.s  to  denote  the  PTS  representation  of  the  constructors  zero  and 
SUCC  An  integer  list  of  length  one  has  the  type  ListNat(succ(zero)).  This  would  be  represented 
as:  Indip,  1,  |succp/.s(/crop/.s)|). 

The  representation  of  constructors  contains  the  representation  of  the  inductive  definition.  For 
example,  the  constructor  nil  is  represented  as  Conip,  1,  1,  []).  This  says  that  nil  is  the  first  con¬ 
structor  in  the  first  set  of  definitions  in  p,  and  the  set  of  arguments  for  this  constructor  is  empty. 

In  the  presentation  in  Chapter  5  we  had  a  built-in  primitive  recursion  operator  that  we  called 
Elim.  In  our  implementation,  we  use  two  other  built-in  operators,  a  Case  construct  and  a  recursion 
construct  ( Fix  )  to  simulate  this.  The  formation  rules  and  the  reduction  rules  for  these  constructs 
is  entirely  standard.  This  approach  was  formalized  and  proved  equivalent  to  the  primitive  recursive 
approach  in  [Gim98,  HPM+00].  We  used  the  same  formalization  in  our  implementation. 

Case(p,pi,p')  p'j  Pi  . .  .p" 
where  Pl  =  Con(p3 ,  i,  j,  \p'( , . . . ,  p"  ] ) 

The  PTS  representation  of  the  case  construct  is  explicitly  typed.  The  first  sub-term  p  gives  the 
type  of  the  case  construct;  the  next  sub-term  pi  is  the  term  being  analyzed  (which  must  have  an 
inductive  type);  and  the  list  pl  is  the  set  of  branches  for  the  case  statement.  Every  branch  must  bind 
the  arguments  of  the  corresponding  constructor;  these  arguments,  p"  . . .  p”,  arc  passed  in  during 
the  reduction. 

Our  recursive  construct  can  include  several  mutually  recursive  definitions,  but  the  syntax  in¬ 
cludes  special  restrictions  to  prevent  non-normalizing  terms.  One  of  the  arguments  of  the  Fix 
construct  must  have  an  inductive  type.  This  is  the  argument  that  we  will  recurse  on.  The  body  of 
F ix  must  start  with  a  case  analysis  of  this  inductive  argument.  As  pointed  before,  the  case  analysis 
binds  the  arguments  of  the  constructors  to  variables.  Recursive  calls  arc  allowed  only  on  these 
variables.  Intuitively,  the  recursion  can  occur  only  on  the  subterms  of  an  inductively  defined  term. 
Therefore,  the  syntax  of  F ix  must  specify  which  argument  is  being  recursed  on. 
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The  abstract  syntax  for  a  set  of  mutually  recursive  definitions  is  the  following: 

Fix j  (  f  \  / i  i  .  A\  —  . . .  fn/in:An  —  Bn ) 

The  body  of  /).  is  £>/,.  and  it  has  the  type  A^.  In  the  body  /i/.,  we  will  recurse  over  the  ikth  argument. 
We  are  interested  in  the  jth  definition.  We  will  use  Fixj(F)  to  denote  this  definition.  At  every 
occurrence  this  fixpoint  must  be  applied  to  ij  arguments,  where  the  ijth  argument  must  have  an 
inductive  type.  The  reduction  rule  (shown  below)  is  standard:  however,  the  reduction  is  applied 
only  if  A'ij  (the  ijth  argument)  is  syntactically  a  constructor.  This  restriction  is  needed  to  ensure 
strong  normalization,  and  corresponds  to  the  reduction  for  primitive  recursive  operators. 

Fixj(F)  A[...  A%  ([(Fixk(F)/fk)k=1...n\Bj)  A\  . . .  A% 

The  PTS  representation  of  this  fixpoint  occurrence  is  shown  below: 

Fix(i,p,j,p') 
where  i  =  [i\, . . . ,  in\ 

P  Fn(S eq[A\pfS , . . . ,  AnpfS] .  Seq[B\p^s: . . . ,  Bnp^sJ) 

P1  =  [^1  ptSl  ij-lptg] 

As  before  we  use  a  Fn  construct  to  bind  the  sequence  of  variables  f\  . . .  fn  in  the  bodies  B.ipts. 
The  list  of  integers  i  specifies  the  argument  in  each  recursive  definition  that  is  being  recursed  on. 
The  list  of  terms  //  carries  all  the  arguments  previous  to  the  one  that  is  being  recursed  on. 

The  Seq  and  Proj  constructs  arc  mainly  an  implementation  aid.  The  Seq  construct  is  used  for 
binding  a  list  of  pterms,  for  example  the  set  of  constructors  in  an  inductive  definition.  By  using 
the  Seq  construct  we  ensure  through  our  hash-consing  scheme  (Section  6.3)  that  there  is  only  a 
single  copy  of  the  list  in  memory.  If  we  use  an  explicit  list  of  pterms  then  each  component  of  the 
list  would  be  shared;  however,  we  would  still  have  multiple  copies  of  the  list.  Moreover,  the  Seq 
and  Proj  constructs  allow  us  to  handle  a  list  of  terms  without  any  meta-level  machinery.  Since 
environments  can  also  be  modelled  as  a  list  of  bindings,  these  constructs  arc  also  used  for  sharing 
environments. 
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6.2  Rationale  for  design  decisions 


The  main  motivations  in  designing  the  representation  of  PTS  terms  were  to  provide  fast  type  manip¬ 
ulation,  and  to  make  type-checking  convenient.  These  were  reflected  mainly  in  the  representation 
of  inductive  definitions,  and  elimination  forms  for  these  inductive  definitions.  In  this  section  we 
will  explain  why  we  chose  these  representations  with  some  simple  examples. 

Constructors:  During  type  reductions  constructors  arc  mainly  used  for  analysis  in  the  Case 
construct.  Consider  the  reduction  of  a  case  statement:  Case(pi,p2,p').  We  need  to  figure  out 
whether  pi  is  a  constructor,  and  if  so,  the  arguments  of  the  constructor.  Since  our  representation 
for  a  constructor  carries  all  its  arguments,  we  have  the  invariant  that  a  term  is  a  constructor  if 
and  only  if  its  representation  is  of  the  form  Con(p\ ,  On  the  other  hand  if  the  constructor 

was  explicitly  applied  to  arguments,  we  would  have  to  deconstruct  a  sequence  of  applications,  and 
determine  whether  the  term  at  the  head  was  a  constructor.  Moreover,  our  representation  also  makes 
it  easy  to  recover  the  arguments. 

In  the  representation  for  a  constructor  Con(p\ ,  i,  j,  //).  the  term  p\  contains  the  definition  of  all 
the  constructors  in  the  corresponding  inductive  definition.  Even  though  this  seems,  at  first  glance, 
to  be  an  overkill,  it  does  not  incur  a  significant  overhead.  First,  our  hash-consing  mechanism 
(Section  6.3)  ensures  that  there  is  only  a  single  copy  of  p i  in  memory;  all  occurrences  of  the 
constructors  of  an  inductive  definition  share  the  same  copy. 


A  I ~  I  :  A  where  I  =  lnd(A :  A){C} 

A  h  Ctor(z,I)  :  [I/X]Ci 

Second,  consider  the  typing  rule  for  a  constructor  shown  above  (we  are  considering  just  a  simple 
inductive  definition).  The  type  of  a  constructor  is  obtained  by  substituting  the  bound  variable  by 
the  inductive  definition  [I /X]Ci.  In  the  general  case  of  a  mutually  inductive  definition,  each  of  the 
bound  variables  will  have  to  be  substituted.  Our  representation  for  constructors  makes  this  easy 
since  p\  encapsulates  the  entire  inductive  definition. 

Inductive  definition:  Parametrized  inductive  definitions  are  represented  as  Ind(pi,i,p'),  where 
7/  arc  the  values  of  the  parameters.  Consider  the  parametrized  definition  of  lists  that  we  saw  before: 
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Inductive  (ListNat:Nat  —  Kind) 

=  nil  :  ListNat(zero) 

|  cons  :  HX  :Nat.  int  — >  ListNat(AT)  — >  ListNat(succ(2f)) 

In  the  type  of  the  constructors,  ListNat  is  fully  applied  to  arguments.  Since  an  inductive  def¬ 
inition  occurs  with  its  parameters  instantiated,  we  again  maintain  an  invariant  similar  to  the  con¬ 
structors:  a  term  is  an  inductive  definition  if  and  only  if  it  has  the  form  Ind(p\,i,p').  Moreover, 
when  we  check  the  positivity  condition  of  the  constructors,  we  have  to  check  that  the  arguments  of 
a  parametrized  definition  satisfy  certain  constraints.  Our  representation  makes  it  easy  to  extract  the 
arguments. 

Fixpoint  definition:  We  use  a  similar  mechanism  for  our  fixpoint  definitions:  namely,  the  rep¬ 
resentation  includes  all  the  arguments  till  the  one  that  is  being  recursed  on.  For  example  in 
Fix(i,pi,j,p'),  the  list  7/  includes  the  first  ij  —  1  arguments.  During  type  reductions,  the  fixpoint 
(as  shown  before)  is  unfolded  only  if  the  i1-1  argument  is  a  constructor.  During  type-checking,  we 
have  to  check  that  this  argument  has  an  inductive  type.  Our  representation  makes  it  easy  to  access 
this  argument.  The  term  p\  uses  the  standard  encoding  of  fixpoints  as  functions. 

6.3  Implementation  Details 

Implementing  a  type  system  in  an  industrial-strength  compiler  is  a  very  difficult  problem;  a  naive 
implementation  can  easily  add  an  exponential  overhead  to  the  compilation  time.  Fortunately,  previ¬ 
ous  researchers  have  implemented  scalable  implementations  of  type-preserving  production  compil¬ 
ers  [SLM98].  We  used  many  of  the  excellent  ideas  in  [SLM98,  Nad94]  to  make  our  implementation 
efficient.  We  kept  the  following  criteria  in  mind:  compact  space  usage,  fast  equality  operation,  and 
efficient  type  reductions. 

Compact  space  usage:  As  we  showed  in  Figure  6.2  large  types  are  ubiquitous  in  real-world 
applications.  This  happens  specially  in  highly-modularized  programs  because  a  module  interface 
gets  exposed  through  multiple  access  paths.  As  a  result  the  amount  of  type  information  that  needs  to 
be  manipulated  multiplies  rapidly;  however,  this  type  information  also  has  a  lot  of  redundancy.  It  is 
crucial  that  an  implementation  exploit  this  redundancy  in  representing  types  efficiently.  Therefore 
we  hash-cons  all  PTS  terms  into  a  global  hash  table.  Our  hash-consing  scheme  guarantees  that  all 
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PTS  terms  use  the  most  compact  dag  representation.  To  protect  against  space  leaks,  we  use  weak 
pointers  for  every  hash  entry. 

Fast  type  equality  operation:  Our  hash-consing  scheme  also  enables  a  very  fast  type  equality 
operation.  Since  we  use  DeBruijn  indices  for  variables,  cr- equivalent  terms  have  the  same  repre¬ 
sentation.  Hash-consing  ensures  that  all  of  these  terms  share  the  same  representation  in  memory. 
Moreover,  for  types  in  normal  form,  we  can  test  for  equality  by  using  pointer  equality.  If  the  types 
arc  not  in  normal  form,  then  we  reduce  the  types  to  weak-head  normal  form  and  check  the  heads 
for  equality.  If  the  heads  arc  equal,  we  continue  recursively  on  the  sub-terms.  In  practice,  this  leads 
to  fast  equality  tests. 

Efficient  type  reductions:  We  use  a  combination  of  lazy  reductions  and  memoization  to  make 
type  reductions  efficient.  For  lazy  reductions,  we  add  a  form  of  suspension  terms  [NW90,  Nad94, 
SLM98]  to  our  PTS  calculus  through  the  Clos  construct.  Intuitively,  these  suspension  terms  arc 
a  form  of  closures:  they  arc  a  pair  of  a  type  and  an  environment  containing  the  values  of  the 
free  variables.  Reductions  change  the  nesting  depth  of  PTS  terms  which  changes  the  DeBruijn 
indices  of  variables.  Therefore,  the  environment  formed  during  a  reduction  must  remember  both 
the  required  substitutions  and  the  change  in  DeBruijn  indices.  Accordingly,  the  environments  arc 
represented  as  a  triple  ( i,j ,  env)  where  the  first  index  i  indicates  the  current  embedding  level  of 
the  term,  the  second  index  j  indicates  the  embedding  level  after  the  reduction,  and  the  env  is  a 
mapping  between  variables  (DeBruijn  indices)  to  terms. 

Figure  6.3  shows  how  we  use  these  suspension  terms.  Since  the  sort  of  a  variable  plays  no  role 
in  the  reductions,  we  represent  variables  only  by  their  DeBruijn  index.  We  use  V ar{  1)  to  denote 
the  innermost  lambda  bound  variable.  During  a  /3-reduction,  instead  of  performing  the  substitution 
directly,  we  create  a  suspension  term.  The  environment  represents  the  following:  the  term  p 2  that 
was  originally  in  the  scope  of  1  abstraction  is  now  under  none;  originally  under  the  scope  of 
0  abstractions  is  to  be  substituted  for  the  first  free  variable  in  p-2-  In  the  other  cases  we  propagate 
the  suspensions  through  to  the  subterms.  This  allows  us  to  do  the  substitution  lazily;  we  query  the 
environment  only  when  we  encounter  a  variable  during  type  manipulations.  In  the  case  of  a  free 
variable,  we  simply  adjust  its  DeBruijn  index;  in  the  case  of  a  bound  variable,  we  use  the  value 
from  the  environment. 

We  memoize  type  reductions  to  ensure  that  the  same  reduction  is  not  repeated.  For  example. 
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App(Fn(pi,p2),P3) 

Clos(p2 ,  (1,0,  Sub((p3 , 0) ,  Emp)))  (/?  —  redex) 

Clos(Var(n),  ( i,j ,  era;)) 

Var(n  —  i  +  j)  n  >  i  (free  variable) 

Clos(Var(n),  ( i,j ,  era;)) 

Clos(p\,  (0,  j  -  j',  Emp)) 

n//lc lenient  of  era;  =  (j',pi)  (bound  variable) 

Clos(Fn(pi,p2),  ( i,j ,  era;)) 

Fn(pr?jv(pi),ext^v(p2)) 

Clos(Pi(p1,p2),(i,j ,  era;)) 

Pi  {prf™  (pi ) ,  (p2 ) ) 

Clos(App(p1,p2),(i,j,  era;)) 

App(pr^v(pi),pr^v(p2)) 

Clos(Ind(pi,i,p '),  (i,j,  era;)) 

/ nd(pr^jv (pi),i, pr {jp' ) ) 

Clos(Con(pi,i,j,p'),(i,j,  era;)) 

C on(prfjv (pi),i,  j, prf^v (p1) ) 

Clos(Fix(i,pi ,  j, p'),  ( i ,  j,  era;)) 

Fix(i, prfjv (pi ),j, pr^v{p')) 

Clos(Case(pi,p2,p'),  ( i,j ,  era;)) 

Case(prfjv  (Pl ) ,  pr\J  (p2 ) ,  prfj  (p')) 

Clos(Seq(p '),  (■ i,j ,  env )) 

Seq(prfjv (p')) 

Clos(Proj(pi,k ),  (i,j,  env)) 

Proj(prfjv(pi),k) 

Clos(Srt(s),  _) 

Srt(s) 

where 

Prfjv(p)  =  Clos(p,(i,j,env)) 

extfjv(p)  =  Clos(p,(i  +  l,j +  l,Sub((j,Var(l)),env))) 

Figure  6.3:  Using  suspension  terms  for  lazy  reduction 
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suppose  we  have  the  term  p  =  App(Fn(p\  ,P2),P's)-  Suppose  the  term  p  gets  reduced  to  the  term 
p'  =  Clos(p2 ,  (1,0,  Sub((p3,  0),  Emp ))).  After  the  reduction  we  update  the  hash  entry  for  p  to 
contain  the  term  p1.  Any  future  table  lookup  (during  future  creations)  for  the  term  p  will  now  return 
the  term  p' . 

The  hash-table  entry  for  every  term  stores  additional  information.  We  memoize  the  set  of  free 
variables,  whether  a  term  is  in  normal  form,  and  the  universe  that  it  resides  in  (whether  it  is  a  type, 
kind,  or  kind  schema).  The  set  of  free  variables  is  useful  in  applying  substitutions,  the  normal  form 
flag  is  useful  in  equality  testing,  and  the  universe  is  useful  in  checking  inductive  definitions. 

6.4  Representing  the  base  kind 

We  showed  in  Chapter  5  that  the  key  issue  in  using  our  type  system  for  a  compiler  intermediate 
language  was  to  define  the  base  kind  fi.  Correspondingly  we  must  also  define  the  types  that  arc 
members  of  Q  such  as  primitive  types,  function  types,  polymorphic  types,  etc.  We  also  showed 
that  to  support  runtime  type  analysis,  the  base  kind  must  be  defined  inductively.  In  this  section,  we 
show  the  definition  of  fl  used  in  the  implementation. 
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Inductive  Nat:  Kind 


:=  zero 

succ 

Inductive  0 :  Kind 

:=  snat 

Nat 

Nat  — >  Nat 

Nat— >0 

(*  singleton  int  *) 

1  + 

QList  — 

(*  sum  constructor  *) 

1  F 

n j :  Kind,  (j  ->  j)  ->  O' 

-»•  n)  -»•  n 

(*  recursive  constructor  *) 

1  V 

IT/ :  Kind.  0  — ►  fl)  — >  fi 

(*  polymorphic  constructor  *) 

|  3 

I Jj :  Kind.  0  — ►  £2)  — > 

(*  existential  constructor  *) 

1  - 

VtList—^VtList—^Vt 

(*  function/functor  constructor  *) 

|  X 

Nat  — >  QList  — >  f! 

(*  tuple/structure  constructor  *) 

|  cont 

QList  — rfl 

(*  continuation  type  *) 

|  box 

0— 

(*  box  type  *) 

azero 

(*  arity  zero  primitives  *) 

|  aone 

(*  arity  one  primitives  *) 

Inductive  ttList:  Kind 

:=  nil  :  QList 

cons  :  f)  — >  QList  — »  flList 

The  base  kind  uses  the  definition  of  natural  numbers  shown  above.  The  kind  O  is  itself  a  mu- 

tually  recursive  definition.  We  use  QfAst  to  encode  a 

list  of  types. 

Our  function  type  constructor 

works  on  multiple  arguments  and  return  values;  therefore  it  takes  arguments  of  kind  VtList.  Our 
tuple  type  constructor  carries  the  length  of  the  tuple.  The  definition  of  the  polymorphic  and  existen¬ 
tial  constructors  follows  from  Chapter  3.  The  box  type  constructor  is  used  for  data  representation 
and  the  cont  type  constructor  is  used  during  CPS  conversion.  The  azero  and  aone  arc  used  for 
primitive  types.  Arity  zero  primitive  types  include  int31  (31  bit  integers),  int32,  real,  string,  void, 
and  the  primitive  exception.  Arity  one  primitive  types  include  the  list  constructor,  array,  ref,  vector, 
exception  tag,  and  the  primitive  box  constructor. 

6.4.1  Example:  Flattening  arguments 

Standard  ML  provides  single  argument/return-value  functions;  multiple  values  arc  simulated  by 
using  tuples.  Since  it  is  more  efficient  to  pass  the  components  of  the  tuple  as  multiple  arguments 
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or  return  values,  the  SML/NJ  compiler  flattens  the  arguments  and  the  return  values  of  a  function. 
However,  the  flattening  is  done  only  if  the  corresponding  tuples  have  less  than  9  elements.  The  type 
system  in  the  compiler  isn’t  powerful  enough  to  express  these  sort  of  transformations.  The  imple¬ 
mentation  gets  around  this  in  two  ways.  First,  the  function  type  constructor  (—»)  enjoys  a  “special” 
status:  it  includes  a  number  of  flags  that  indicate  whether  the  argument  or  the  result  are  candidates 
for  flattening.  These  arc  term-level  boolean  flags,  and  arc  used  for  reifying  the  type  translations  to 
the  meta-level.  The  implementation  then  checks  the  value  of  these  flags  and  performs  a  number 
of  ad  hoc  reductions  (solely  on  the  function  type)  to  work  around  the  problem.  Second,  a  lot  of 
the  checking  is  done  at  the  meta-level  and  not  through  the  type  system.  For  example,  the  type  sys¬ 
tem  does  not  enforce  that  only  tuples  with  less  than  9  elements  will  be  flattened.  Clearly,  such  an 
approach  is  unsatisfactory  and  we  will  show  how  our  type  system  can  obviate  these  disadvantages. 

This  example  also  shows  how  our  type  system  generalizes  previous  approaches  to  intensional 
type  analysis.  In  our  system  we  can  analyze  tuples  of  arbitrary  length,  or  function  types  with 
an  arbitrary  number  of  arguments  or  return  values.  This  is  possible  because  our  mechanism  for 
inductive  definitions  allows  us  to  define  a  list  of  types  QList..  We  can  now  say  that  our  tuple 
type  constructor  takes  a  list  of  types,  and  abstract  away  the  length.  All  previous  approaches  to 
intensional  type  analysis  were  applicable  only  to  restricted  forms,  such  as  pairs,  or  k-argument 
functions.  In  fact,  Morrisett  [Mor95]  also  shows  how  to  use  type  analysis  for  flattening  function 
arguments,  but  he  considers  functions  with  a  fixed  number  of  arguments. 

We  will  consider  only  the  type-level  transformations;  the  term-level  transformations  arc  well 
known.  Moreover,  the  SML/NJ  compiler  already  implements  the  term-level  flattening  by  using 
coercions  in  the  manner  of  Shao  [Sha97a].  Previous  researchers  have  also  used  similar  coercions 
for  implementing  optimizing  compilers  [SA95,  Ler92], 

We  have  already  shown  the  inductive  definition  of  natural  numbers  used  in  our  implementation. 
We  use  the  inductive  mechanism  to  define  a  boolean  kind  as  well,  containing  two  null  ary  construc¬ 
tors  true  and  false.  We  have  also  implemented  a  library  of  useful  primitive  recursive  functions  on 
values  of  these  inductive  kinds.  Note  that  these  arc  type-level  functions  operating  on  type-level 
values.  For  example,  on  natural  numbers  we  provide  functions  for  addition  or  comparison;  on 
booleans  we  provide  functions  for  doing  conjunction,  disjunction,  or  negation. 


104 


flatten  =  Fn(X  :QList, 

Case  X 

nil  =  nil 

COns(Fi,  y2)  =CaseY2 

nil 


fbranches  =Fn(X':Q, 
Case  X' 
xx  (N,Y') 


=  Case  N 

zero 

succ(7V') 


=  m) 


=  fbranches  Yx 

=  X) 


=  [ X']  (*  void  type  *) 

=  Case  (Leq  N'  8) 
true  =  Y’ 
false  =  [X’} 


where  [X']  =  cons(X'.nil) 

8  =  succ(. . .  succ(zero)) 

' - v - ' 

8 

We  define  a  type-level  flatten  operator  as  shown  above.  We  have  taken  some  liberties  with  the  PTS 
syntax  to  make  the  presentation  clearer:  we  use  named  variables  instead  of  DeBruijn  indices,  elide 
some  typing  annotations,  and  use  pattern  matching  syntax  for  case  statements.  The  Leq  function 
is  paid  of  the  library  of  functions  that  we  have  implemented.  We  won’t  show  the  code  here  since  it 
is  straightforward  (specially  because  we  use  a  unary  encoding). 

A  function  with  type  A\  — >  A 2  has  the  type  flatten  A\  —>  flatten  ,4 2  after  flattening.  The 
flatten  operator  first  checks  that  the  function  has  1  argument/return-value.  If  this  is  true,  it  calls  the 
fbranches  function.  This  function  checks  if  the  argument  is  a  tuple,  and  has  a  length  between  1 
and  9,  before  flattening  it.  The  checking  is  possible  since  we  store  the  length  in  the  type  of  a  tuple. 
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Benchmark 

No  of  lines 

Description 

Mlyacc 

6030 

parser  generator  for  ML 

Vliw 

3679 

instruction  scheduler  for  a  VLIW  compiler 

CML 

6152 

concurrent  ML  implementation  by  Reppy  [Rep91] 

Simple 

915 

a  spherical  fluid  dynamics  program 

lexgen 

1171 

lexical  analyzer  for  ML 

Figure  6.4:  Benchmark  programs 


Benchmark 

New 

User  GC 

Old 

User  GC 

Ratio 

(New/Old) 

Lexgen 

5.82 

1.52 

3.48 

0.97 

1.64 

Simple 

4.47 

0.70 

3.70 

0.88 

1.15 

Vliw 

35.14 

6.13 

15.24 

5.49 

1.99 

ML-Yacc 

30.61 

5.07 

14.01 

2.57 

2.15 

CML 

17.51 

2.85 

5.27 

0.69 

3.41 

Figure  6.5:  Compilation  times  (seconds) 


6.5  Performance  measurement 

In  this  section  we  compare  the  performance  of  our  implementation  with  that  of  Standard  ML  of 
New  Jersey  vl  10.34.  This  is  a  highly-tuned  industrial  strength  compiler  that  is  extensively  used 
inside  Bell  Labs  and  many  other  institutions.  We  will  be  comparing  only  the  compilation  statistics 
since  both  the  compilers  generate  identical  code.  To  recap,  our  implementation  uses  a  type  system 
based  on  the  calculus  of  inductive  constructions,  while  the  current  implementation  uses  a  type 
system  based  on  the  simply  typed  lambda  calculus.  Our  implementation  uses  inductively  defined 
kinds,  dependent  and  polymorphic  kinds  and  supports  primitive  recursion  at  the  type  level. 

The  set  of  type -preserving  phases  is  the  same  in  both  the  compilers.  We  instrumented  the 
compilers  to  measure  the  amount  of  type  information  generated  during  the  compilation.  We  used 
the  existing  timing  mechanism  in  the  Standard  ML  of  New  Jersey  implementation;  the  compilation 
times  were  measured  with  the  instrumentation  turned  off.  The  measurements  were  taken  on  a 
Pentium  II,  450  MHz  machine  running  Linux  with  128MB  memory.  Figure  6.5  describes  the 
benchmark  programs  used  in  the  measurements.  As  can  be  seen  all  of  these  arc  substantial  real- 
world  ML  applications. 

Figures  6.5  through  6.7  present  the  measurements.  We  use  New  to  denote  our  implementa¬ 
tion,  and  Old  to  denote  the  Standard  ML  of  New  Jersey  vl  10.34  compiler.  Figure  6.5  shows  a 
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Benchmark 

New 

Old 

Ratio  (New/Old) 

Lexgen 

329.71 

96.98 

3.40 

Simple 

227.07 

66.63 

3.40 

Vliw 

886.92 

222.86 

3.97 

ML-Yacc 

2930.24 

577.86 

5.07 

CML 

1867.34 

395.90 

4.71 

Figure  6.6:  Generated  type  information  (in  KBytes) 


Benchmark 

Code  Size 

Type  Size 

Ratio  (Type/Code) 

Lexgen 

96.15 

18.38 

19% 

Simple 

80.15 

12.76 

16% 

Vliw 

262.56 

22.99 

8% 

ML-Yacc 

348.62 

206.50 

59% 

CML 

125.97 

149.03 

118% 

Figure  6.7:  Ratio  of  type  size  to  code  size  (in  KBytes) 


comparison  of  the  compilation  times.  As  the  figures  show,  the  maximum  overhead  incurred  by  our 
implementation  is  about  a  factor  of  three.  Correspondingly  Figure  6.6  shows  that  the  amount  of 
type  information  generated  during  the  compilation  process  increases  by  about  a  factor  of  four. 

The  code  generated  by  a  type -preserving  compiler  contains  type  annotations  embedded  inside 
it.  Figure  6.7  compares  the  size  of  these  type  annotations  to  the  size  of  the  generated  code.  Both  the 
type  size  and  the  code  size  were  measured  at  the  end  of  the  type -preserving  phases  of  the  compiler 
(just  before  closure  conversion).  In  a  type-based  certifying  compiler,  the  types  serve  as  the  proof 
of  safety.  Therefore,  this  table  gives  a  measure  of  the  size  of  the  proof  (of  type-safety)  compared 
to  the  size  of  the  code.  In  all  cases,  the  type  size  is  a  fraction  of  the  code  size.  The  ratio  increases 
in  the  case  of  CML.  We  assume  it  happens  because  CML  is  heavily  functorized  which  causes  the 
type  information  to  grow  dramatically. 

While  the  figures  indicate  that  the  new  type  system  does  incur  an  appreciable  overhead,  a  better 
tuned  implementation  can  remove  a  significant  amount  of  this  inefficiency.  Our  main  motivation 
was  to  examine  how  an  expressive  type  system  scales  to  handle  real-world  ML  applications.  We 
will  elaborate  on  a  number  of  design  decisions  that  can  be  changed  to  make  the  implementation 
significantly  faster. 

•  Our  definition  of  O  includes  a  definition  of  ilList,  and  most  of  our  constructors  take  a  list 
of  types  as  an  argument.  By  using  a  more  sophisticated  encoding  of  QList,  the  amount 
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of  type  information  being  constructed  can  be  reduced.  Suppose  for  example  that  we  want 
to  build  a  sum  type  int  +  real.  In  our  implementation  we  would  then  construct  the  term 
+  (cons(intpfe,  cons(realpts,  nil))).  A  list  of  n  types  requires  2n+1  nodes  in  this  represen¬ 
tation. 

We  could  instead  use  the  following  representation  for  a  list  of  types: 

Inductive  QList  :  Kind  :=  nil  :  QList 

j  consl  :  fl  — ►  flList 
|  cons2  :  Q  — >  fl  — >  flList 
|  cons3  :  O  — ^  O  — s-  — s-  QLi.st 

|  cons  :  fl  — >  flList  — >  QList 

We  have  separate  constructors  till  a  particular'  value  of  n,  say  m.  Lists  of  length  smaller  than 
m  only  require  an  extra  node  now.  Experiments  show  that  the  list  of  types  is  usually  small; 
thus  only  a  few  constructors  would  be  sufficient. 

•  In  the  old  compiler  type  constructors  were  built-in  primitives;  they  were  implemented  as 
different  branches  of  a  datatype.  The  compiler  used  pattern  matching  to  check  the  form  of 
the  constructor  at  the  head:  whether  it  was  a  function,  tuple,  sum,  array,  vector,  etc.  This 
form  of  pattern  matching  is  specially  pervasive  in  the  code  that  deals  with  type-directed 
optimizations.  In  the  new  implementation  the  type  constructors  are  members  of  an  inductive 
definition.  The  compiler  code  can  no  longer  use  pattern  matching  to  detect  the  form  of  a 
constructor.  The  compiler  optimizations  can  be  re-written  to  obviate  this  problem,  but  this 
would  have  involved  a  major  redesign  of  almost  the  entire  type-directed  part  of  the  compiler. 
Instead  we  provided  some  utility  functions  that  simulate  pattern  matching.  These  functions 
are  executed  at  every  pattern  matching  site  in  the  code;  measurements  show  that  this  incurs 
a  considerable  overhead. 

•  For  simplicity  our  type  system  used  a  unary  encoding  of  the  natural  numbers.  Again  this 
introduces  a  considerable  overhead,  specially  during  arithmetic  operations.  We  could  remove 
this  by  using  the  binary  encoding  of  the  Coq  [HPM  00]  math  library. 

•  The  type  system  in  the  current  compiler  uses  multiple  argument  functions.  Our  functions 
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on  the  other  hand  (the  Fn  construct)  arc  single  argument  functions.  Using  multiple  argu¬ 
ment  functions  is  much  more  efficient,  specially  in  mutually  recursive  inductive  definitions. 
In  essence  our  implementation  has  to  simulate  multiple  argument  functions  by  passing  the 
arguments  as  a  record  of  types,  and  selecting  from  this  record.  Since  Q  is  a  mutually  re¬ 
cursive  inductive  definition,  and  is  ubiquitous,  this  adds  a  considerable  overhead  to  the  type 
manipulations. 

6.6  Related  Work 

Many  of  the  ideas  in  our  implementation  have  been  adapted  from  Shao  et  al.  ’s  excellent  work 
[SLM98]  on  implementing  typed  intermediate  languages.  They  were  the  first  to  demonstrate  that 
typed  intermediate  languages  can  be  used  in  industrial-strength  compilers.  Several  other  compilers 
such  as  TIL  [TMC+96],  GHC  [Pey92],  and  ML-Kit  [Tof98]  have  demonstrated  the  benefits  of 
using  typed  intermediate  languages.  The  suspension  based  lambda  encoding  used  in  our  work  is 
borrowed  directly  from  the  work  of  Nadathur  [Nad94,  NW90]  on  efficient  lambda  representations. 
He  has  also  used  his  encoding  in  the  A-Prolog  system.  Shao  and  Appel  [SA95]  also  used  hash- 
consing  to  enforce  dag-representation  for  types. 

We  adapted  a  lot  of  the  theoretical  underpinnings  of  our  implementation  from  the  Coq  [  HPM  1  00] 
system.  The  combination  of  the  F ix  and  the  Case  construct  used  for  simulating  primitive  recursion 
is  borrowed  directly  from  there.  The  Coq  system  in  turn  uses  the  formalism  by  Gimenez  [Gim98]. 
Our  inductive  definition  mechanism  is  more  sophisticated  than  the  one  presented  in  Chapter  5 ;  in 
this  case  also  we  used  the  formalism  of  the  Coq  system. 
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Chapter  7 


Conclusions  and  Future  Work 


Certifying  compilation  is  a  promising  approach  for  implementing  secure  computing  systems,  since 
it  provides  a  static  and  incontrovertible  proof  of  a  program’s  safety.  Type -preserving  compilation 
has  emerged  as  the  practical  basis  for  constructing  a  certifying  system  leading  to  the  concept  of 
type-based  certifying  compilers.  In  a  type-based  certifying  compiler,  the  type  system  for  the  inter¬ 
mediate  language  is  used  to  encode  safety  properties;  the  type  annotations  in  the  generated  code 
serve  as  the  proof  of  safety. 

Modern  programming  paradigms  arc  increasingly  giving  rise  to  applications  that  require  run¬ 
time  type  analysis.  Services  such  as  garbage  collection,  dynamic  linking  and  reflection,  mar¬ 
shalling,  and  type-safe  persistent  programming  all  analyze  types  to  various  degrees  at  runtime. 
Existing  compilers  use  an  untyped  intermediate  language  for  compiling  code  that  involves  runtime 
type  inspection.  They  reify  types  into  values  and  discard  type  information  at  some  early  stage  dur¬ 
ing  compilation.  Unfortunately,  this  approach  cannot  be  used  in  type-based  certifying  compilers; 
such  compilers  must  support  runtime  type  analysis  in  a  type-safe  manner. 

Writing  these  type-analyzing  applications  in  a  certifying  framework  is  desirable  for  a  number 
of  reasons.  A  computing  system  is  only  as  secure  as  the  services  that  it  provides:  typically  these 
services  include  type-analyzing  applications  like  garbage  collection,  linking,  reflection,  etc.  More¬ 
over,  these  applications  often  involve  complex  coding  that  can  lead  to  subtle  bugs.  There  is  also  a 
software  engineering  benefit.  For  example,  in  a  type-safe  garbage  collector,  the  interface  and  in¬ 
variants  must  be  made  explicit  through  the  types.  Type-checking  now  ensures  that  these  invariants 
arc  respected  whenever  the  collector  is  invoked. 

This  dissertation  describes  a  type  system  that  can  be  used  for  supporting  runtime  type  analysis 
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in  type-based  certifying  compilers.  The  type  system  has  two  novel  features.  First,  it  supports  the 
analysis  of  quantified  types.  Second,  it  supports  the  explicit  representation  of  logical  proofs  and 
propositions. 


7.1  Summary  of  contributions 

The  core  contribution  of  this  dissertation  is  a  type  system  for  analyzing  the  type  of  runtime  values, 
but  this  system  has  other  important  ramifications.  The  type  system  can  be  used  for  type-checking 
the  copy  function  in  a  stop-and-copy  garbage  collector,  and  thus  provides  a  significant  basis  for 
writing  provably  type-safe  garbage  collectors.  The  underlying  ideas  can  also  be  used  for  integrating 
logical  assertions  in  a  type  system,  and  enforcing  more  sophisticated  invariants.  To  sum  up: 

•  We  show  the  design  of  a  type  system  that  supports  the  analysis  of  quantified  types,  both 
at  the  type  level  and  at  the  term  level.  We  prove  that  the  resulting  type  system  is  strongly 
normalizing  and  confluent.  We  also  show  an  encoding  of  the  calculus  in  a  type-erasure 
semantics.  We  prove  that  this  encoding  is  sound  by  establishing  a  correspondence  with 
reductions  in  an  untyped  language. 

•  We  show  that  this  type  system  can  be  applied  for  writing  the  copy  function  in  a  copying 
garbage  collector  in  a  type-safe  manner.  We  show  that  type-checking  this  function  relies 
crucially  on  the  ability  to  analyze  quantified  types,  like  existential  types.  We  prove  that  the 
language  in  which  the  copy  function  is  written  is  sound.  Our  formalization  does  exclude 
some  features  of  an  industrial-strength  collector,  nevertheless  it  represents  a  significant  step 
towards  designing  a  type  system  that  can  be  used  for  realistic  garbage  collectors. 

•  We  show  that  the  ideas  (underlying  the  analysis  of  quantified  types)  can  be  extended  to 
integrate  runtime  type  analysis  with  the  explicit  representation  of  logical  proofs  and  proposi¬ 
tions.  Again,  we  prove  that  the  resulting  type  system  is  strongly  normalizing  and  confluent, 
and  the  underlying  logic  is  consistent. 

•  We  show  empirically  that  the  type  system  can  be  used  in  an  industrial-strength  compiler.  For 
this,  we  implemented  the  system  in  an  experimental  version  of  the  SML/NJ  compiler  and 
compared  its  performance  with  version  1 10.34  of  the  compiler.  On  a  set  of  large  benchmarks, 
our  measurements  show  that  the  new  type  system  incurs  a  reasonable  compilation  overhead. 
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7.2  Future  work 


The  work  presented  in  this  dissertation  is  a  first  step  towards  the  goal  of  building  a  practical  in¬ 
frastructure  for  certified  type  analyzing  applications.  It  opens  up  many  possible  avenues  for  future 
work. 

In  this  dissertation  we  showed  how  a  type  system  for  runtime  type  analysis  can  be  used  in 
building  a  type-safe  copying  garbage  collector.  But  we  could  use  this  for  many  other  applications. 
Type-safe  serialization  is  a  promising  candidate  for  translation  into  the  framework  proposed  in 
Chapter  3.  One  of  the  key  problems  here  is  the  handling  of  abstract  types;  we  need  some  mech¬ 
anism  to  break  abstraction  barriers.  This  is  similar  to  the  problem  we  encountered  in  writing  the 
polymorphic  equality  function  where  we  have  to  compare  two  objects  of  existential  type  (Sec¬ 
tion  3.3.1).  Modelling  reflection  in  Java  seems  another  promising  candidate  since  it  provides  a 
facility  that  is  similar  to  intensional  type  analysis.  However,  the  framework  presented  in  Chapter  3 
relies  on  structural  equivalence  of  types,  whereas  Java  uses  name  equivalence  of  types.  Moreover, 
translating  Java  into  a  type-preserving  framework  would  require  the  use  of  recursive  types.  Extend¬ 
ing  intensional  type  analysis  to  handle  recursive  types  still  remains  an  open  problem.  In  separate 
work  [STSOOa,  TSSOO]  we  have  shown  different  methods  of  analyzing  recursive  types,  but  unfor¬ 
tunately,  these  approaches  turn  out  to  be  impractical.  We  believe  that  the  encoding  of  recursive 
types  proposed  by  Shao  [ShaOl]  (and  shown  in  Chapter  6)  will  lead  to  a  satisfactory  solution,  but 
the  details  remain  to  be  worked  out. 

In  Chapter  4  we  showed  how  the  copy  function  in  a  simple  copying  garbage  collector  can  be 
written  in  a  provably  type-safe  manner.  However,  there  arc  still  quite  a  few  issues  that  need  to 
be  resolved  before  constructing  a  practical  type-safe  garbage  collector.  In  separate  work  [MSS01] 
we  have  shown  how  generational  collectors  may  be  modelled.  The  solution  assumes  that  we  can 
maintain  a  separate  region  for  mutable  data  that  gets  scanned  at  each  collection.  This  assumption 
may  not  be  feasible  for  object-oriented  languages  where  side-effects  arc  more  frequent.  We  will 
have  to  support  either  card-marking  or  remembered  sets.  Our  presentation  also  does  not  deal  with 
the  problem  of  cyclic  data  structures.  An  interesting  area  of  work  would  be  to  model  Cheney  style 
collectors. 

The  work  in  Chapter  5  opens  up  many  possibilities  in  the  area  of  type -based  language  design 
and  compilation.  Our  implementation  preserves  types  through  the  different  optimizations  and  dis¬ 
cards  them  before  closure  conversion.  In  separate  work  [SSTP01]  we  have  shown  how  to  propagate 
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types  through  CPS  conversion  and  closure  conversion.  One  possible  area  of  work  is  to  propagate 
these  advanced  types  down  to  the  machine  code.  Can  we  use  the  expressivity  to  capture  more 
invariants:  for  example  to  enforce  tine-grained  access  policies  during  memory  load  and  store  in¬ 
structions,  or  to  enforce  calling  conventions  for  native/foreign  methods  ?  Appel  and  Felten  [AFOOa] 
have  shown  that  the  PCC  framework  can  be  used  for  enforcing  a  wide  variety  of  security  policies 
such  as  correct  sequencing  of  API  calls  and  correct  locking  protocols;  they  use  Church’s  higher 
order  logic  for  this.  Since  our  framework  is  powerful  enough  to  support  reasoning  in  higher-order 
predicate  logic,  it  would  be  interesting  to  model  similar  invariants  in  our  system.  Another  pos¬ 
sible  area  of  research  is  to  augment  a  source  language  with  the  capability  of  expressing  logical 
assertions.  For  many  non-trivial  invariants,  the  compiler  would  need  hints  from  the  programmer  to 
prove  that  they  arc  satisfied.  It  would  be  impractical  for  the  programmer  to  insert  these  hints  in  the 
object  code:  we  should  rather  provide  a  facility  to  add  these  assertions  in  the  source  program  itself. 

From  a  practical  standpoint,  our  implementation  can  be  made  more  robust.  The  measurements 
in  Chapter  6  show  that  the  compilation  time  with  the  new  type  system  increases  by  a  factor  of  3-4. 
It  should  be  possible  to  reduce  this  overhead  significantly.  In  Chapter  6  we  listed  a  number  of 
design  decisions  that  can  be  changed  to  obtain  a  much  better  performance,  at  the  cost  of  making 
the  implementation  more  involved.  Most  importantly,  we  want  to  use  the  implementation  to  build 
realistic  certified  applications;  for  example,  a  type-safe  garbage  collector.  This  will  give  us  a  true 
measure  of  the  overhead  involved  in  writing  certified  applications. 

Finally,  we  want  to  apply  this  technology  to  the  compilation  of  mainstream  languages  such 
as  Java.  The  object  oriented  paradigm,  and  specially  Java,  present  very  different  challenges  from 
those  encountered  in  compiling  ML-like  languages:  efficient  object  encodings  in  a  typed  frame¬ 
work,  name-based  class  hierarchy,  mutually  recursive  classes,  class  loaders,  dynamic  loading,  and 
finalization  to  name  a  few.  We  believe  that  the  real  test  of  this  technology  lies  in  its  successful 
application  to  the  compilation  of  such  languages. 

The  long  term  goal  of  our  research  is  to  build  an  industrial-strength  certifying  framework. 
Every  piece  of  code  should  be  shipped  with  a  formal  and  verifiable  proof  of  its  safety.  In  addition, 
the  host  system  should  have  a  really  skelatal  trusted  computing  base.  The  TCB  will  include  the 
verifier  and  some  bootstrapping  code,  but  all  the  other  services  should  be  verified  independently 
and  loaded  as  libraries.  We  believe  this  is  feasible  and  is  the  holy  grail  of  secure  computing. 
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Appendix  A 


Formal  Properties  of  Xf 

L 

In  this  chapter,  we  formalize  the  properties  of  A  f.  We  show  that  the  type  system  is  sound  with 
respect  to  the  operational  semantics.  We  also  show  that  all  reductions  in  the  type  language  arc 
terminating  and  confluent. 

A.l  Soundness  of  X- 

The  operational  semantics  for  Xf  arc  in  Figure  A.3.  The  reduction  rules  arc  standard  except  for 
the  typecase  construct.  The  typecase  chooses  a  branch  depending  on  the  head  constructor  of 
the  type  being  analyzed  and  passes  the  corresponding  subtypes  as  arguments.  For  example,  while 
analyzing  the  polymorphic  type  V  [k]  r,  it  chooses  the  ey  branch  and  applies  it  to  the  kind  n  and 
the  type  function  r.  If  the  type  being  analyzed  is  not  in  normal  form,  the  typecase  reduces  the 
type  to  its  unique  normal  form. 

We  prove  soundness  of  the  system  by  using  contextual  semantics  in  Wright/Felleisen 
style  [WF92].  The  evaluation  contexts  E  arc  shown  in  Figure  A.l.  The  reduction  rules  for  the 
redexes  r  arc  shown  in  Figure  3.7.  We  assume  unique  variable  names  and  environments  arc  sets  of 
variables.  The  notation  F  e :  t  is  used  as  a  shorthand  for  e;  e;  s  \~  e:r. 

Lemma  A. 1.1  If  e\  eh  v  :  Cl,  then  v  is  one  of  int,  — >  V2,  V  [k]  v\,  or  V+  u\. 

Proof  Since  v  is  well-formed  in  an  empty  environment,  it  does  not  contain  any  free  type  or  kind 
variables.  Therefore  v  can  not  be  a  u°  since  the  head  of  a  u°  is  a  type  variable.  The  lemma  now 
follows  by  inspecting  the  remaining  possibilities  for  u.  □ 
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i  |  Xx\T.e  |  f  ix  x :  r.  v  |  A  a  :k.v  |  A +j.  v 

[\\  Ee\vE  \  E[t]\  E[k}+ 

(Ax  :r.e)v  \  (A a :  ft.  v )  [r]  |  (A +j.  e )  [ k]+ 
(fix x'.t.v)  v1  |  (fi Xx:t.v)[t'] 

(fix  X-.T.V )  [ft]+ 

typecase[r]  r'  of  (eint;  e^;  ev;  ey) 
typecase[r]  int  of  (eint;  e^;  ev;  e^) 

typecase[r]  r  — >  r'  of  (ejnt;  e^;  ey;  e^f) 
typecase[r]  V  [ft]  r  of  (eint;  e^;  ev;  e^) 
typecase[r]  V+r  of  (eint;  e^;  ev;  e^) 


Figure  A.  1 :  Term  contexts 


a  |  ft0  ft  |  ft0  [ft] 

Typerec[ft]  of  (ftint;  w;  v) 

|  int  |  — »  |  (— »)  v  |  (— »)ftz/ 

V  I  V  [ft]  I  V  [ft]  V  I  V+  I  V+ft 
Aa :  ft.  ft,  where  Vft°.  ft  /  ft0  a  or  a  G  ftv(u°) 
A j.  ft,  where  Vft°.  ft  /  ft0  [j]  or  j  €  fkv (ft0) 

Figure  A.2:  Normal  forms  in  the  type  language 


Lemma  A.1.2  (Decomposition  of  terms)  //V  e :  r,  f/zon  either  e  A  a  va/ne  or  it  can  be 
decomposed  into  unique  E  and  r  such  that  e  =  E  [r]. 

This  is  proved  by  induction  over  the  derivation  of  F  e :  r,  using  Lemma  A.  1. 1  in  the  case  of  the 
typecase  construct. 

Corollary  A. 1.3  (Progress)  If  F  e :  r,  then  either  e  is  a  value  or  there  exists  an  e'  such  that 


Proof  By  Lemma  A.  1.2,  we  know  that  if  F  e :  r  and  e  is  not  a  value,  then  there  exist  some  E  and 
redex  e\  such  that  e  =  E  [ei].  Since  e\  is  a  redex,  there  exists  a  contraction  e2  such  that  e.  \  e2- 

Therefore  ewe'  for  e'  =  E  □ 

Lemma  A. 1.4  If  F  E  [e] :  r,  then  there  exists  a  t'  such  that  F  e:r',  and  for  all  e'  such  that 
F  e'  :t'  we  have  F  E  [e'\ :  r. 


(value)  v  ::= 
(context)  E  ::= 
(redex)  r  ::= 
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(Ax : r.  e)  v \v/x\ e  (fi X  x :  r.  x)  r/ ([fix  x:t.v/x]v)  v' 

(A a:  ac.  x)[t]  [r/a]x  (fix x: r.  x)[r]  ([fix  x:  r.  x/x]x)[r] 

(A+j.x)[k]+  \k/ j\v  (fix  x'.t.v) [k]+~>  ([fix  x : r.  x/x]x) [k]+ 

e  e!  e  e1  e!  e' 

eei^e'ei  ve^ve'  e[r]  ^  e'fr]  e[«;]+ c'[k]+ 

typecase[r]  int  of  (ejnt;  e^;  ey;  e^)  eint 

typecase[r]  (n  —  r2)  of  (eint;  e^;  ev;  e^)  [ri]  [r2] 
typecase[r]  (V  [k]  t)  of  (eint;  e^;  ev;  e^)  ev  [k]+  [r] 

typecase[r]  (V+r)  of  (eint;  e^;  ev;  e^f)  ^  e ^  [r] 

s:  £  F  t'  v' :  O  7/  is  a  normal  form 

typecase[r]  r'  of  (ejnt;  e^;  ev;  eyO 

typecase[r]  z/  of  (eint;  e^;  ey;  e^r) 

Figure  A.  3:  Operational  semantics  of  A!f 


Proof  The  proof  is  by  induction  on  the  derivation  of  F  E  [e] :  r.  The  different  forms  of  E  are 
handled  similarly;  we  will  show  only  one  case  here. 

•  case  E  =  E\  e\:  We  have  that  F  (E\  [e] )  ei :  r.  By  the  typing  rules,  this  implies  that 

F  E\  [e] : ti  — >  r,  for  some  t\.  By  induction,  there  exists  a  t'  such  that  Fe:r'  and  for  all  e' 
such  that  F  e! :  r',  we  have  that  F  E\  [e'\ :  ti  — *  r.  Therefore  F  (E\  [e'])  ei :  r.  □ 

As  usual,  the  proof  of  soundness  depends  on  several  substitution  lemmas;  these  are  shown  below. 
The  proofs  arc  fairly  straightforward  and  proceed  by  induction  on  the  derivation  of  the  judgments. 
The  notion  of  substitution  is  extended  to  environments  in  the  usual  way. 

Lemma  A.1.5  If£,j  F  k  and  £  F  k' ,  then  £  F  [E  /  j\  k. 

Lemma  A.1.6  If£,j ;  A  F  r  :  k  and  £  F  n! ,  then  £;  A [d /j\  F  [d /j\r  :  [k! /j\n. 

Lemma A.1.7  If£,j-,A;T  F  e  :  t  and  £  F  k,  then  £;  A[k/j];  Y[n/j\  F  [n/j]e  :  [n/j]r. 

Lemma  A.1.8  lf£\  A,  a :  k'  F  t  :  nand£;A\-  t'  :  k' ,  then  £;  A  F  [t1  /a\r  :  k. 
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Lemma  A.1.9  lf£\  A,  a :  k;  T  h  e  :  t  and  £]  A  h  t'  :  n,  then 
£;A -,T[t' /a]  h  [r'/aje  :  [V/c^t. 

Proof  We  prove  this  by  induction  on  the  structure  of  e.  We  demonstrate  the  proof  here  only  for  a 
few  cases;  the  rest  follow  analogously. 

•  case  e  =  e\  [ti]  :  We  have  that  £;  A  b  t'  :  k.  and  also  that  £;  A,  a :  k;  T  h  ei  [ti]  :  r.  By 
the  typing  rule  for  a  type  application  we  get  that 

£;  A  , a: k; r  h  ei  :  V/3 : «i. T2  and 
f;A  ,  a :  k  h  ri  :  K\  and 
r  =  [ti/P\t2 

By  induction  on  ei, 

<S;  A;  r [t'/q\  h  [r'/aje  1  :  V/5 :  n\.  [r'/afo 
By  Lemma  A.  1.8,  £;  A  h  [r'/ajri  :  k  1 .  Therefore 

A;r[r7a]  h  ([r'/ajei)  [[r'/aln]  :  [[T,/a]T1//?]([T7a]r2) 

But  this  is  equivalent  to 

£-A-T[t'/o\\- ([T'/a\ei)[[T'/a]Ti}  :  [t’ /  a\(\ri  /  (3\t2) 

•  case  e  =  ei  [ki]+:  We  have  that  £;  A,  a :  k;  T  h  e\  [ki]+  :  r  and  f;Ahr'  :  k.  By  the 
typing  rule  for  kind  application, 

£\  A,  a:  k;  T  h  ei  :  Vj.  ti  and 
r  =  [ki/j]ti  and 
£  h  K\ 

By  induction  on  ei, 

£;  A;  T  h  [r'/aje  1  :  Vj.  [t'/oi}ti 

Therefore 

A;T  h  ([r'/a]ei)  [«i]+  :  [«i/j](['r7Q;]r1) 

Since  j  does  not  occur  free  in  r', 

[«i/j](['r7«]ri)  =  [r7a]([Ki/j]n) 
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•  case  e  =  typecasefro]  T\  of  (eint;  e^;  ey;  e^r):  From  the  typing  rules,  we  have  that 

£;  A  b  t'  :  k  and  £;  A,  a:  n;  T  F  typecase[r0]  t\  of  (ejnt;  e^;  ey;  e^r)  :  Tori.  Using 
Lemma  A.  1.8  on  the  kind  derivation  of  to  and  r±,  and  the  inductive  assumption  on  the 
typing  rules  for  the  subterms  we  get, 

£;  A  I-  [r'/ajro  :  U  — ►  U  and 

£;  A  I-  [r'/a]ri  :  f2  and 

<F;  A;  Tfr'/a]  F  [r'/ajeint  :  [r'/a](ro  int)  and 

£;  A;  Tfr'/a]  F  [r'/aje^  :  [r'/a](Vai  :fL  Va2  :U.  to  (an  — >  02))  and 
£;  Ajrfr'/a]  F  [r'/ajey  :  Va:j  — >  fi.  To  (V  [7]  a))  and 

£;  A;  T[t'/q\  F  [r'/aje^f  :  [rVa](Va:Vj\  U.  to  (V+ct)) 

The  above  typing  judgments  arc  equivalent  to 

£;  A  F  [r'/ajTo  :  U  — >  U  and 

£;  A  F  [t' /a\T\  :  U  and 

<F;  A;  Tfr'/a]  F  [r'/crjeint  :  ([r'/a]ro)  int  and 

£]  A;  T[t'/q\  F  [r'/aje^  :  V«i  :H.  (['r//a]ro)  («i  — *  02)  and 

£;  AjTfr'/a]  F  [r'/ajey  :  V+j.Va:y  — >  U.  ([r'/ajro)  (V  \j\  a)  and 
£\  A\T\t' / oi\  F  [r'/aje^f  :  Va:  Vj.  £l.  ([r'/ajro)  (V+a) 

from  which  the  statement  of  the  lemma  follows  directly.  □ 

Lemma  A.l. 10  If£;  A;  T,  x:  t'  F  e  :  t  and  £;  A;T  e1  :  t',  then  £;  A;  T  F  [e' /x\e  :  r. 

Proof  Proved  by  induction  over  the  structure  of  e.  The  different  cases  are  proved  similarly.  We 
will  show  only  two  cases  here. 

•  case  e  =  A  a  :n.v:  We  have  that 

£;  A;  T,  x:t'  F  Act:  k.  v  :  \/a:n.T  and 
£;A;T  F  e!  :  r’ 

Since  e  can  always  be  alpha-converted,  we  assume  that  a  is  not  previously  defined  in  A. 
This  implies  £;  A,  a :  k;  T,  x  :  t'  F  v  :  r.  Since  a  is  not  free  in  e',  we  have 
£;A ,a:K;TFe'  :  r'.  By  induction,  £;  A, cr: k; T  F  [e'/rcjn  :  r.  Hence 
£]  A;  T  F  Aa:  re.  [e'/xjn  :  \/a:n.T. 

•  case  e  =  typecase[ro]  Ti  of  (eint;  e^;  ey;  e^f):  We  have  that 
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£;  A;  T  h  e'  :  t'  and 

£]A ;T,x:t'  h  typecase[r0]  r,  of  (eint;  e^;  ev;  e^)  :  Ton 

By  the  typecase  typing  rule  we  get 

£ ;  A  b  ro  :  — ►  17  and 

<5 ;  A  h  n  :  U  and 

<5;  A;  T,  x:r' h  eint  :  To  int  and 

£;A;r  ,x:t'  h  :  Vaq : U.  Va2  :fl.  to  (aq  — ►  0:2)  and 

£;  A;  T,  x:t'  b  ey  :  V+j.  Va:j  — >  12.  To  (V  [j]  a)  and 

£]  A;  T,  x:t'  b  e^e  :  Va:Vj\  U.  to  (V+a) 

Applying  the  inductive  hypothesis  to  each  of  the  subterms  ejnt,  e_>,  ey,  (yi  yields  directly 
the  claim.  □ 

Definition  A. 1.11  e  evaluates  to  e!  ( written  e  1— >  er)  if  there  exist  E,  ei,  and  e-2  such  that 
e  =  E  [ei]  and  e'  =  E  [ef\  and  e\  e2. 

Theorem  A.1.12  (Subject  reduction)  If\~  e :  t  and  e  1— >  e7,  b  e' :  t. 

Proof  By  Lemma  A.  1.2,  e  can  be  decomposed  into  unique  E  and  unique  redex  ei  such  that 
e  =  E  [ei] .  By  definition,  e'  =  E  [e2]  and  ei  ^  e2-  By  Lemma  A.  1.4,  there  exists  a  t'  such  that 
b  ei : t' .  By  the  same  lemma,  all  we  need  to  prove  is  that  \~  holds.  This  is  proved  by 
considering  each  possible  redex  in  turn.  We  will  show  only  two  cases,  the  rest  follow  similarly. 

•  case  c\  =  (fix  x\T\.v)v'\  Then  e2  =  ([fix  x\t\.v/x\v)  v' .  We  have  that 

b  (fix  x :  T| .  v) )./  :  t' .  By  the  typing  rules  for  term  application  we  get  that  for  some  T2, 

b  f  ix  x :  T\ .  v :  T2  — ►  t'  and 

h':T2 

By  the  typing  rule  for  fix  we  get  that, 

h  Ti  =  T2  — >  t'  and 

e;  e;  e,  x :  t-2  — >  t'  b  v  :  t-2  — ►  r' 

Using  Lemma  A.  1.10  and  the  typing  rule  for  application,  we  obtain  the  desired  judgment 
b  ([fix x:t\.  v/x\v)  v'  : t' 

•  case  ei  =  typecase[To]  Ti  of  (eint;  e^;  ey;  fyi ):  If  t\  is  not  in  normal  form,  then  the 
expression  e\  reduces  to  e2  =  typecase[To]  iq  of  (eint;  e^;  ey;  eyf),  where 
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(kinds)  n  ::=  17  |  k  — ►  k'  \  j  \  \/j.n 

(types)  t  ::=  int  |  — *  |  V  |  V+ 

|  a  |  A  j.  t  |  A  ar.K.r  \  r  [k]  |  tt' 
j  Typereef/cj  t  of  (rint;  t_^;  rv;  v) 


Figure  A.4:  The  Xf  type  language 


(Pi)  : 

:=  (A oc:k.t)t'  [V/a]T 

(ft)  = 

:=  (Aj.  t)  [k]  [k/j']t 

(»7i)  : 

:=  A ar.n.Tot^T  a  ^  ftv(r) 

(m)  : 

:=  Aj.  t  [j]  t  j  i  fkv(r) 

(h)  : 

:=  Typerecfrc]  int  of  (Tint;  t_^;  tv;  v)  ^  Tint 

(*2)  : 

:=  Typerecfrc]  (n  -»•  t2)  of  (Tint;  t_^;  tv;  v) 

T_>  Tl  T2 

(Typerec[«]  n  of  (Tint;  t_^;  tv;  t^)) 

(Typerec[K]  t2  of  (Tint;  t_^;  tv;  v)) 

(*3)  : 

:=  Typerec[/c]  (\/[m)  n)  of  (Tint;  t_^;  tv;  v)  ^ 

A/  [«l]  A 

(Aa:K!.Typerec[K]  Ora)  of  (Tint;  t_^;  tv;  t^)) 

(t4)  : 

:=  Typerecfs]  (V+n)  of  (Tint;  t^;  tv;  t^) 

Vri 

(Aj.  Typerec[«]  (n  [j])  of  (rmt-  t_;  tv;  v)) 

Figure  A.5:  Type  reductions 

e;  e  F  t\  i— >*  :  17.  The  latter  implies  s;  £  F  To  t\  =  To  :  17.  hence  F  e2 :  r'  follows 

directly  from  F  ei :  t'  . 

If  r i  is  in  normal  form  z/] ,  by  the  second  premise  of  the  typing  rule  for  typecase  and 
Lemma  A.  1.1  we  have  four  cases  for  u\.  In  each  case  the  contraction  has  the  desired  type 
To  7/ 1 ,  according  to  the  corresponding  premises  of  the  typecase  typing  rule  and  the  rules  for 
type  and  kind  applications.  □ 


A.2  Strong  normalization 

The  type  language  is  shown  in  Figure  A.4.  The  single  step  reduction  relation  (t  t')  is  shown 
in  Figure  A.  5. 
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Lemma  A.2.1  If£\  Ahr  :  k  and  r  ^  t'  ,  then  £;  A  \~  t'  :  n. 


Proof  (Sketch)  The  proof  follows  from  a  case  analysis  of  the  reduction  relation  (^ ).  □ 

Lemma  A.2.2  If  n  ^  t%  then  [t/ck]ti  [t/o\t2- 

Proof  The  proof  is  by  enumerating  each  possible  reduction  from  n  to  72. 
case  /3i :  In  this  case,  n  =  (A/3 :  n.  t')  t"  and  T2  =  [t"//3\t'.  This  implies  that 

[t/o\ti  =  (A P'.k.  [ t/o\t' )  [■ r/a]r " 

This  beta  reduces  to 

[[T/a\T"/P\([T/a\T') 

Since  (3  does  not  occur  free  in  r,  this  is  equivalent  to 

[r/a}([r"/P\Tf) 

case  /?2 :  In  this  case,  ti  =  (A j.  t')  [k]  and  r2  =  [k/J]t'.  We  get  that 

[r/ajn  =  (A j.  [t/ol]t')  [k] 

This  beta  reduces  to 

[«/j]  [t/ol\t' 

Since  j  is  not  free  in  r,  this  is  equivalent  to 

[r/a]([K/j]r') 

case  771:  In  this  case,  n  =  A /3:k.t'  [3  and  r 2  =  t'  and  (3  does  not  occur  free  in  t' .  We  get  that 

[r/a]ri  =  A (3:k.  ([r/a]r/)  (3 

Since  this  is  a  capture  avoiding  substitution,  (3  still  does  not  occur  free  in  .  Therefore  this 

eta  reduces  to  [t/q\t' . 
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case  7/2 :  In  this  case,  t\  =  A j.  t'  \j\  and  r2  =  t'  and  j  does  not  occur  free  in  t' .  We  get  that 


[t/ol\t x  =  Aj.  {[t/ol]t')  [j] 

Since  this  is  a  capture  avoiding  substitution,  j  still  does  not  occur  free  in  [r/ajr7.  Therefore,  this 
eta  reduces  to  [r/ajr'. 

case  t\\  ri  =  Typerec[/i]  int  of  (rjnt;  r_^;  rv;  r^)  and  T2  =  Tint.  We  get  that 

[r/a]n  =Typerec[K]  int  of  ([r/a]rin t;  [r/a]r_^;  [r/a]rv;  [r/ajr^) 

But  this  reduces  by  the  t \  reduction  to  [r/a]rint. 

case  t2'-  t\  =  Typerec[fi]  (V  — >  t")  of  (rmt;  r_^;  rv;  r^-)  and 

r2  =  r_^  r' t"  (Typerec[«]  r'  of  (rint;  r_^;  rv;  r^))  (Typerec[/€]  r"  of  (rint;  r_^;  rv;  r^)) 

We  get  that 

[r / a]r i  =  Typerecf/t]  ([r/ajr'  -*■  [r/ajr")  of  ([r/a]Tint;  [r/a]r_^;  [r/a]rv;  [r/a]^) 
This  reduces  by  t2  to 

[r/a]r_^  ([r/ajr')  ([r/a]r") 

(Typerec[/i]  ([t/o!]t')  of  ([r/a]Tint;  [r/a]r^;  [r/a]rv;  [r/ajr/-)) 

(Typerec[K]  ([r/a]r")  of  ([r/a]rint;  [t/o:]t_;  [r/a]rv;  [r/ajr^)) 

But  this  is  syntactically  equal  to  [r/a]r2. 

case  £3:  ri  =  Typerec[K]  (V  [«/]  t')  of  (rint;  r^;  ry;  r^-)  and 

T2  =  rv  [«']  t'  (A/^rc'.Typerec^]  (r'/3)  of  (rmt;  t_^;  rv;  r/)) 


We  get  that 

[r/a]ri  =  Typerec[K]  (¥[«']  [r/a]r')  of  ([r/a]rint;  [r/a]r^;  [r/a]rv;  [r/a]^) 


122 


This  reduces  by  ts  to 


[r/a]rv  [«/]  ([t/o\t') 

(A/3 :ac'.  Type rec[«]  (([r/a]r,)/3)  of  ([r/a]rint;  [r/a]r_^;  [r/a]rv;  [r/ajr^)) 

But  this  is  syntactically  equivalent  to  [r/a'jr^. 

case  £4:  ri  =  Typerec[fi]  (V+ r')  of  (Tjnt;  r_^;  ry;  rv+)  and 

T2  =  vr/  (Aj.  Typerec[/C]  (r'  \j])  of  (rin t;  r_^;  rv;  r^)) 


We  get  that 

[r/a]ri  =  Typerec[«]  (V+[t/«]t/)  of  ([r/a]rint;  [r/a]r_^;  [r/a]rv;  [r/ajr^) 

This  reduces  by  34  to 

[T/a]T^([T/a]T/) 

(Aj. Typerec[/c]  (([r/ajr')  [j])  of  ([r/a]Tint;  [r/a]r_^;  [r/a]rv;  [r/ajr^)) 

But  this  is  syntactically  equal  to  [t/ol]t2- 

Lemma  A.2.3  If  T\  72,  f/?cn  \k'  /  j'\r\  ^  W/f]T2. 

Proof  This  is  proved  by  case  analysis  of  the  type  reduction  relation, 
case  ff:  In  this  case,  n  =  (A/3  :k.t')  t"  and  72  =  [t"/(3\t'.  This  implies  that 

W/f  ]n  =  (A/3:  W/f  ]«.  K/i'lr')  [k'/jV 


This  beta  reduces  to 

IW/jV/PW/jV) 


But  this  is  equivalent  to 


W/jW/PW) 


case  fa:  In  this  case,  n  =  (A j.  t')  [re]  and  72  =  [k/ j]r' .  We  get  that 


W/f]ri  =  (A j.  W/j'}r')  [[«'//]«] 


This  beta  reduces  to 

Since  j  is  not  free  in  re7,  this  is  equivalent  to 

case  r)\.  In  this  case,  n  =  \/3:k.t'  (3  and  r2  =  r7  and  (3  does  not  occur  free  in  r7.  We  get  that 

W/j'jri  =  A/3:  [k'/ZK  (K/7'V)  P 

Again  f3  does  not  occur  free  in  [k' /j']r'.  Therefore  this  eta  reduces  to  [k' /j'jr'. 

case  r/2 :  In  this  case,  t\  =  A  j.  t7  [j]  and  72  =  r7  and  j  does  not  occur  free  in  r7.  We  get  that 


W/j']Tl=Aj.(W/j']T')\j] 


Since  this  is  a  capture  avoiding  substitution,  j  still  does  not  occur  free  in  [k//j/]t/.  Therefore,  this 
eta  reduces  to  [re7/j7]r7. 

case  t\\  t\  =  Typerec[re]  int  of  (rjnt;  t_>;  7v;  r^r)  and  T2  =  Tint.  We  get  that 

K/j'M  =  Typerec[[re7//]re]  int  of  {[k!  / j']rmX.-,  [re'/j'lr-A  [k7/]w;  [«7/]v) 

But  this  reduces  by  the  fi  reduction  to  [n' / 

case  t2 :  t\  =  Typerec[re]  (r7  — >  r")  of  (rmt;  r_^;  Ty;  r^r)  and 

r2  =  r_^  r7  t"  (Typerec[re]  r7  of  (rint;  r^;  rv;  r^))  (Typerec[re]  r77  of  (rint;  r^;  rv;  r^)) 

We  get  that 

W/3']ti  =  Typerec[[re7/j7]re]  ([re7/j7]r7  [re7/j7]r77)  of 

(K/j7]7int;  W/j']T^  W/fW,  W/j'W) 
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This  reduces  by  t<2  to 


[K'/j']T^{[K'/jy){[K'/j']T") 

(Typerec [[«'//]«]  ([«7jV)  of  [n'/j'y [k'/J'W,  [«'//] v)) 

(Typerec[[«7/]«]  {W/j'}r")  of  ([«'//] Tnt;  [«7/]^;  [«7/]w;  K/i'M) 

But  this  is  syntactically  equal  to  [«///] r2- 

case  ts:  r±  =  Typerec[fi]  (V  [«i]  t')  of  (rint;  r^;  rv;  r^t-)  and 

T2  =  TV[Ki]T'(A/?:Ki.Typerec[K;]  (V/3)  of  (rint;  r_^;  rv;  r^)) 


We  get  that 

W/j']n  = 

Typerec[[/«7/]/c]  (V[[«7/]ki]  jV/jV)  of 
(W/j']TmU  W/ j'}T^\  W/j'W,  W/j'jT^) 

This  reduces  by  £3  to 


W/f]rAW/f}^](W/jV) 
(A/3:[K7/]«i-Typerec[[/c7/]K]  {{W/j'V)  0)  of 
(W/fWf,  W/f]r u;  K/j']tv;  K/j'M) 


But  this  is  syntactically  equivalent  to  W/f]T2. 

case  t±\  t\  =  Typerec[/>]  (\/V)  of  (r\nt',  t_»;  rv;  r^-)  and 


T2  =  vr'  (Aj.  Typerec[K]  (V  [j])  of  (rint;  t_^;  rv;  r^)) 


We  get  that 


[«7/]n  = 

Typerec[[«7/]«]  (vV/j']r')  of  (W/f]vint-  W/j'jr^  W/j'W,  [«7/]v) 
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This  reduces  by  to 


(AJ\Typerec[[KVy]Kj(([«7/]r')[j])of([K7/]rint;  W/j']r^  W/fW,  [«7/]v)) 

But  this  is  syntactically  equal  to 

Definition  A.2.4  A  type  r  is  strongly  normalizable  if  every  reduction  sequence  from  t  terminates 
into  a  normal  form  (with  no  redexes).  We  use  n(r)  to  denote  the  length  of  the  largest  reduction 
sequence  from  t  to  a  normal  form. 

Definition  A.2.5  We  define  neutral  types,  n,  as 
no  ::=  A j.  r  |  A ot.k.t 
n  ::=  a  |  no  r  |  n  r  |  no  [n]  |  n[n] 

|  Typerec[n]  r  of  (rint;  t^;  rv;  r^) 

Definition  A.2.6  A  reducibility  candidate  ( also  referred  to  as  a  candidate)  of  kind  k  is  a  set  C  of 
types  of  kind  n  such  that 

1.  ifr€.C,  then  r  is  strongly  normalizable. 

2.  if  t  £  C  and  r  ^  t' ,  then  t'  £  C. 

3.  if  t  is  neutral  and  if  for  all  t'  such  that  r  ^  t'  ,  we  have  that  t'  £  C,  then  r  £  C. 

This  implies  that  the  candidates  arc  never  empty  since  if  a  has  kind  n,  then  a  belongs  to 
candidates  of  kind  n. 

Definition  A.2.7  Let  k  be  an  arbitrary  kind.  Let  CK  be  a  candidate  of  kind  k.  Let 
be  a  candidate  of  kind  12— >12— Let  Cyj .  be  a  candidate  of  kind 

Vj.  (j  — r  17)  — >  (j  — >  k)  — >  k.  Let  C(yj  K)-ni  be  a  candidate  of  kind 

(Vj.  12)  — >  (Vj.  k)  — >  k.  We  then  define  the  set  Rq  of  types  of  kind  17  as 
r  £  Rn  iff 
VVjnt  £  CK 

Vt_>  £  C<i  — ,  o  — ,  K — ,  h- — ,  K, 

^7/  £  f-'Vj.  (j — ’Ci) — .(j — .k) — ’ /y ’ 

Vrv-r  £  C(y/j,  n)_ »(Vj.  k)—*k 

=>  Typerec[n]  r  of  (rint;  r^;  rv;  r^)  £  <7 
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Lemma  A.2.8  /?,<  >  is  a  candidate  of  kind  17. 


Proof  Suppose  r  E  Rq.  Suppose  that  the  types  vmt,  r_,,  7y,  and  Tu+  belong  to  the  candidates 
CK,  CVj.  C(v?.  fi)-(v.j.  k)-k  respectively,  where  the  candidates  are 

of  the  appropriate  kinds  (see  definition  A.2.7). 

1.  Consider  t'  =  Typerec[n]  t  of  (Tjnt;  r_^;  Ty;  T^f).  By  definition  this  belongs  to  CK.  By 
property  1  of  definition  A.2.6,  t'  is  strongly  normalizable  and  therefore  r  must  be  strongly 
normalizable. 

2.  Consider  t'  =  Typerec[n]  r  of  (rjnt;  t-»;  rv;  t^).  Suppose  r  ^  n.  Then 
t'  Typerec[n]  ri  of  (7jnt;  r_^;  rv;  r^-).  Since  t'  E  Ck, 

Typerec[n]  n  of  (Tint;  r_>;  rv;  rv )  belongs  to  CK  by  property  2  of  definition  A.2.6. 
Therefore,  by  definition,  n  belongs  to  /(<). 

3.  Suppose  r  is  neutral  and  for  all  t\  such  that  r  n,  ri  G  /fo.  Consider 

t'  =  Typerecjn]  r  of  (rjnt;  r_^;  ry;  r^-).  Since  we  know  that  rint,  r_^,  ry,  and  r^-  are 
strongly  normalizable,  we  can  induct  over  len  =  v(T\nf)  +  n(r_^)  +  z/(ry)  +  i/(u).  We 
will  prove  that  for  all  values  of  len,  Typerec[/>]  r  of  (rjnt;  r_>;  ry;  ry)  always  reduces  to  a 
type  that  belongs  to  CK;  given  that  rint,  r_,  rv,  and  rf  belong  to  CK, 

%  and  C(Vj.  n)^(Vj.  respectively  (see  definition  A.2.7). 

•  Zen  =  0  Then  t'  Typerec[n]  t\  of  (rint;  r_>;  ry;  u)  is  the  only  possible 
reduction  since  r  is  neutral.  By  the  assumption  on  n,  this  belongs  to  CK. 

•  len  =  k  +  1  For  the  inductive  case,  assume  that  the  hypothesis  is  true  for  len  =  k. 
That  is,  for  len  =  k,  Typerecfn]  r  of  (rjnt;  r^;  ry;  ry)  always  reduces  to  a  type  that 
belongs  to  CK\  given  that  rint,  r_^,  rv,  and  r^y  belong  to  CK, 

Cvj.O'- and  C(Vj.  n)_(yj.  «)_«  respectively.  This  implies  that  for 
Zen  =  k,  Typerec[/,:]  r  of  (rint;  t_,;  ry;  ry)  belongs  to  CK  (by  property  3  of 
definition  A.2.6).  For  Zen  =  k  +  1,  consider  r'  =  Typerec[n]  r  of  (Tjnt;  r_>;  ry;  r^-). 
This  can  reduce  to  Typerecfn]  n  of  (rint;  r_^;  ry;  u)  which  belongs  to  CK.  The 
other  possible  reductions  arc  to  Typerec[/.]  r  of  ( r(nt ;  r_^;  ry;  u)  where 
Tnt  ^  T-'nt,  or  to  Typerec[n]  r  of  (r]nt;  ri,.;  ry;  r^y)  where  r_^  ^  ri,,  or 
Typerec[n]  r  of  (rint;  r_^;  r(,;  r^y)  where  rv  Ty,  or 
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Typerec[/,]  r  of  (rint;  r_^;  7\/;  r',. )  where  r;-  r',. .  By  property  2  of 

definition  A.2.6,  each  of  r'mV  rff,  Ty,  and  t'..  belongs  to  the  required  candidate  and 
len  =  k  for  each  of  the  reducts.  Therefore,  by  the  inductive  hypothesis,  each  of  the 
reducts  belongs  to  CK. 

Therefore  Typerec[/v]  r  of  (rint;  r_^;  ry;  Ty\ )  always  reduces  to  a  type  that  belongs  to  CK. 

By  property  3  of  definition  A.2.6,  Typerec[/y)  r  of  ( Tjnt ;  r^;  7y;  lyy)  also  belongs  to  CK. 

Therefore,  r  €  Rq 


□ 


Definition  A.2.9  Let  C\  and  C2  be  two  candidates  of  kinds  k\  and  k2.  We  then  define  the  set 
C\  — >  C  2,  of  types  of  kind  k\  — >  k2,  as 
t  €  Ci  —>  C2  iff  £  C\  t  t'  £  C2) 

Lemma  A.2.10  IfCi  and  C2  are  candidates  of  kinds  ki  and  k2,  then  C 1  — >  C2  is  a  candidate  of 
kind  Ki  — ►  «2. 

Proof 

1.  Suppose  r  of  kind  K\  — ►  k2  belongs  to  C 1  — >  C2.  By  definition,  if  t'  £  Ci,  then  tt'  £  C2. 

Since  C2  is  a  candidate,  r  t'  is  strongly  normalizable.  Therefore,  r  must  be  strongly 
normalizable  since  for  every  sequence  of  reductions  r  n  . . .  Tfe  . . there  is  a 
corresponding  sequence  of  reductions  tt'  n  t'  . . .  tj~  t' _ 

2.  Suppose  r  of  kind  ki  — ►  k2  belongs  to  Ci  — >  C2  and  r  ^  t' .  Suppose  n  £  Ci.  By 
definition,  rq  G  C2.  But  r  ri  ^  t'  t\  .  By  using  property  2  of  definition  A.2.6  on  C2, 
t'  n  £  C2;  therefore,  r'  €  Ci  — >  C2. 

3.  Consider  a  neutral  r  of  kind  K\  —>  k2 .  Suppose  that  for  all  r'  such  that  r  ^  r7, 

t'  £  Ci  — >  C2.  Consider  tti  where  ri  £  C 1.  Since  n  is  strongly  normalizable,  we  can 
induct  over  zz(n  ).  If  z/(n)  =  0,  then  rq  r'  n.  But  t'  n  £  C2  (by  assumption  on  r'), 
and  since  r  is  neutral,  no  other  reduction  is  possible.  If  u(ti)  f  0,  then  n  ^  r{.  In  this 
case,  t  n  may  reduce  to  either  t'  ti  or  to  r  t[ .  We  saw  that  the  first  reduct  belongs  to  C2. 
By  property  2  of  definition  A.2.6,  r{  £  Ci  and  u(t']  )  <  o(t\).  By  the  inductive  assumption 
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over  u(t\  ),  we  get  that  r  t[  belongs  to  C 2.  By  property  3  of  definition  A.2.6,  r  ti  G  C 2.  This 
implies  that  r  6  Ci  — >  C2. 

□ 


Definition  A.2.11  We  use  j  to  denote  the  set  j\. ... .  jn  of  j.  We  use  a  similar  syntax  to  denote  a 
set  of  other  constructs. 

Definition  A.2.12  Let  k  [j  ]  be  a  kind  where  j  contains  all  the  free  kind  variables  of  k.  Let  is  be  a 
sequence  of  closed  kinds  of  the  same  length  and  C  be  a  sequence  of  candidates  of  the 
corresponding  kind.  We  now  define  the  set  SK[Cfj]  of  types  of  kind  [k/J\k  as 

1.  if  k  =  Ll,  then  SK[C/J\  =  Rq. 

2.  if  k  =  ji,  then  SK[Cfj |  =  C%. 

3.  if  k  =  ki  ->•  «2,  then  SK[C/J\  =  SKl[Cfj\  ->  SK2[C/J |. 

4.  if  k  =  Vj.  k' ,  then  SK[C[J\  =  the  set  of  types  r  of  kind  [k/j ]k  such  that  for  every  kind  k" 
and  reducibility  candidate  C"  of  this  kind,  r  [n"}  G  SK/[C,C" /j,  j\. 

Lemma  A.2.13  SK[C /  j]  is  a  reducibility  candidate  of  kind  [k/j]k. 

Proof  For  k  =  Q,  the  lemma  follows  from  lemma  A.2.8.  For  n  =  j,  the  lemma  follows  by 
definition.  If  k  =  k\  — >  k 2,  then  the  lemma  follows  from  the  inductive  hypothesis  on  k\  and  K9 
and  lemma  A.2.10.  We  only  need  to  prove  the  case  for  k  =  Mj'.  n' .  We  will  induct  over  the  size  of 
k  with  the  j  containing  all  the  free  kind  variables  of  k, 

1.  Consider  are  S\jjcK'[C  /  j].  By  definition,  for  any  kind  n\  and  coiTesponding  candidate  C, 
t  [«i]  G  SK'[C,C' /j ,  j'].  Applying  the  inductive  hypothesis  on  n' ,  we  get  that 

SK'[C,C' / j ,  j']  is  a  candidate.  Therefore,  r  [«i]  is  strongly  normalizable  which  implies  that 
r  is  strongly  normalizable. 

2.  Consider  a  r  G  S-sp,  f;>  [C/j]  and  t  ^  t\.  For  any  kind  K\  and  coiTesponding  candidate  C' , 
by  definition,  r  [ki]  G  SK>[C,C'/j,  j'].  But  r  [n \ ]  ^  n  [ki].  By  the  inductive  hypothesis 
on  k',  we  get  that  SK>  [C.  C / j.jf]  is  a  candidate.  By  property  2  of  definition  A.2.6, 

n  [ki]  G  SK>[C,C'/J,j'].  Therefore,  n  G  SVf.K'[C/J\. 
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3.  Consider  a  neutral  r  so  that  for  all  n,  such  that  r  ^  n,  ri  6  iSyf.  K'  [C /j].  Consider  r  [ki  ] 
for  an  arbitrary  kind  K\  and  corresponding  candidate  C .  We  have  that  r  [ki ]  n  [k.|  ]. 
This  is  the  only  possible  reduction  since  t  is  neutral.  By  the  assumption  on  n, 
ri  [«i]  G  <fv  [C,  C'/j,f].  By  the  inductive  hypothesis  on  k',  we  get  that  SK>  [C,  C /j,j'\  is  a 
candidate.  By  property  3  of  definition  A.2.6,  r  [ki]  G  SK>[C,C' /j,j'].  Therefore 
'f  ^  Sw. K,[C/j}. 


□ 


Lemma A.2.14  S[n,  / jl]K[C  / j]  =  SK[C,SK’[C/j]/j,j'} 

Proof  The  proof  is  by  induction  over  the  structure  of  k.  We  will  show  only  the  case  for 
polymorphic  kinds,  the  others  follow  directly  by  induction.  Suppose  k  =  VjA  k" .  Then  the  LHS 
is  the  set  of  types  t  of  kind  [F/fCij" .  \k'  /j']n")  such  that  for  every  kind  k’"  and  corresponding 
candidate  C" ,  r  f"}  belongs  to  S[K>/jnK"[C,C'" /j,j"].  Applying  the  inductive  hypothesis  to  k", 
this  is  equal  to  SK"  [C,  C" ,  SK>  \C,  C'" /j,  j"]/j,  j",  j'}  •  But  j "  does  not  occur  free  in  k!  (valuables  in 
k'  can  always  be  renamed).  Therefore,  r  [k'"]  belongs  to  SK»[C, C" ,SK/[C fj\ The  RHS 
consists  of  types  r'  of  kind  [k,  [k/J]k' /j,j'](\/j" .  n")  such  that  for  every  kind  k!"  and 
corresponding  candidate  C’" ,  t'  \k!"\  belongs  to  SKrr[C,SK/\CfJ\,C'"/j,j',j"].  Also,  the  kind  of 
t'  is  equivalent  to  [F/J\(\/j" .  [k! /j']n").  □ 

Proposition  A. 2. 15  From  lemma  A.2.13,  we  know  that  SK[C  / j ]  is  a  candidate  of  kind  [k  Jj]  k,  that 
/J |  is  a  candidate  of  kind  — *  ft  — >  k  — >  k  — >  k),  that 

S\/j  |  is  a  candidate  of  kind  [k/j](Vj.  (j  — >  ft)  — >  (j  — >  k)  —*  if),  and 

Swj.  n)-»(vy  k)^>k[C/ j\  is  a  candidate  of  kind  [k/j]((Vj.  ft)  — >  (Vj.  n)  — >  k).  In  the  rest  of  the 
section,  we  will  assume  that  the  types  Tjnt,  r_>,  Ty,  and  u  belong  to  the  above  candidates 
respectively. 

Lemma  A.2.16  int  G  Rn  =  Sq [C/j] 

Proof  Consider  r  =  Typerec[[7c/j] /s:]  int  of  (Tjnt;  r_^;  ry;  ry ) .  The  lemma  holds  if 
Typerec[[R/j]  k]  int  of  (rint;  t_^;  ry;  7y+)  belongs  to  Sk[C/k\  is  true;  given  that  Tjnt  G  SK[C/J\, 
and  G  / j],  and  rv  G  «SVj.  / j\,  and 

Tyf  G  <S(\/j . n)_>(vy  k)— ►kP/j] • 
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Since  Tmi,  r_>,  rv,  and  T.+-  arc  strongly  normalizable,  we  will  induct  over 
Zen  =  v{T\nt)  +  n(r_^)  +  v(t\/)  +  v (ryf).  We  will  prove  that  for  all  values  of  Zen, 
Typerec[[K/j]K]  int  of  (rint;  r^  ;  rv;  r,r )  always  reduces  to  a  type  that  belongs  to  CK\  given  that 
the  branches  belong  to  the  candidates  as  in  proposition  A.  2. 15. 

•  len  =  0  Then  Typerec[7f/J]K]  int  of  (rint;  r_>;  rv;  u)  can  reduce  only  to  Tint  which  by 
assumption  belongs  to  SK  [C /k]  . 

•  len  =  k  +  1  For  the  inductive  case,  assume  that  the  hypothesis  holds  true  for  len  =  k.  That 

is,  for  len  =  k,  Typerec[[7c/j']n]  int  of  (rmt;  r_;  rv;  u)  always  reduces  to  a  type  that 
belongs  to  SK\C/J\;  given  that  rint,  r_^,  rv,  and  r/  belong  to  SK\C/J |,  Sn^n^K^K^K{C/J\, 
S\/j.  and  to  5(Vj.  n)^(Vj.  K)^K[C/j].  This  implies  that  for  Zen  =  k,  the 

type  Typerec[[K/7]/v]  int  of  (rint;  r_;  rv;  Tyf)  belongs  to  <SK[C/J]  (by  property  3  of 
definition  A.2.6).  For  Zen  =  k  +  1,  r  can  reduce  to  rjnt  which  belongs  to  St;\C/j].  The 
other  possible  reductions  are  to  Typerec[[n/J|K]  int  of  (r'nt;  r_^;  rv;  rf  )  where 

Tnt  ^  r'nt,  or  to  Typerec[[7r/j]n]  int  of  (rint;  ri>;  rv;  u)  where  r_^  t!_>,  or  to 

Typerecp/J]  k]  int  of  (rjnt;  r_>;  r^,;  u)  where  we  have  rv  ry,  or  otherwise  to 
Typerec[[7c/j]n]  int  of  (rint;  rv;  r^_)  where  tv +-  By  property  2  of 

definition  A.2.6,  each  of  rZnt,  tL,,  ry,  r'r  belongs  to  the  same  candidate.  Moreover,  Zen  =  k 

for  each  of  the  reducts.  Therefore,  by  the  inductive  hypothesis,  each  of  the  reducts  belongs 
to  SK[C/J\. 

Therefore,  TyperecfTc/J]/.:]  int  of  (rjnt;  r_^;  rv;  )  always  reduces  to  a  type  that  belongs  to 
SK[C/J\.  By  property  3  of  definition  A.2.6,  Typerec^n/Jjn]  int  of  (rjnt;  r^:  rv;  ryf)  also 
belongs  to  SK[C/jj.  Therefore,  int  G  R{>.  □ 

Lemma  A.2.17  -»  G  Rq  ->•  Rn  Rn  =  /J\. 

Proof  — »•  G  Rn  — >  /(o  —  7?,o  if  for  all  n  G  7(o,  we  get  that  (  — »)n  G  /(o  — >  7(o.  This  is  true 

if  for  all  T2  G  Rn,  we  get  that  ( — »)n  T2  G  /(<>■  This  is  true  if 

Typerec[  k/j]k]  ( — »)n  T2  of  (rjnt;  r^;  rv;  rr)  belongs  to  <SK[C/j]  is  true  with  the  conditions  in 
proposition  A.2. 15.  Since  n,  r2,  rint,  r_^,  rv,  and  ryf  arc  strongly  normalizable,  we  will  induct 
over  Zen  =  v(t\)  +  1/(72)  +  z/(rjnt)  +  n(r_>)  +  n(ry)  +  z/(r^).  We  will  prove  that  for  all  values 
of  Zen,  the  type  Typerec[[n/j]K]  ((— »)tiT2)  of  (rjnt;  r_>;  rv;  ryf)  always  reduces  to  a  type  that 
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belongs  to  SK[C/J ];  given  that  n  G  /in.  and  t2  G  /in.  and  Tint  G  SK[C/J\,  and 
>  G  /h >  — - o  — - k — - k — - n [C  /  j] ,  ar|d  Ty  G  S\/j.  (j— »n)— >(j— ►«)— and 
V  G  5(Vj.n)^(Vj.K)^K[C/j].  Consider  r  =  Typerec[[«/j]K]  ((^)tit2)  of  (rint;  r_^;  rv;  r^). 

•  ien  =  0  The  only  reduction  of  r  is 

r'  =  T_  Ti  t-2  (Typerec[[7t/j]K]  Ti  of  (rint;  t_^;  rv;  t^-)) 

(Typerec[  [k/j]k]  t2  of  (rint;  t_^;  rv;  r^)) 

Since  both  t\  and  r2  belong  to  /in,  we  get  directly  that 
Typerecp/J]K]  n  of  (rint;  ;  rv;  r^v)  as  well  as 

Typerec[[7i/j]K]  t2  of  (Tint;  t_>;  tv;  Tyr)  belong  to  5K[C/j].  This  implies  that  t'  also 
belongs  to  SK\C/J}. 

•  /en  =  /c  +  1  The  other  possible  reductions  come  from  the  reduction  of  one  of  the  individual 

types  ti,  t2,  Tint,  t _ , ,  tv,  and  u,  The  proof  in  this  case  is  similar  to  the  proof  of  the 

corresponding  case  in  lemma  A.2.16. 

Since  t  is  neutral,  by  property  3  of  definition  A.2.6,  t  belongs  to  SK[C / j ].  □ 

Lemma  A.2.18  If  for  all  t\  G  SK1[Cf]\,  [ti/«]t  G  SK2[C/J\,  then 
\a:[7i/J\Ki.T  G  [C/1]. 

Proof  Consider  the  neutral  type  t'  =  (Aa :  {k/J\k\  .  t)  ti.  We  have  that  ti  is  strongly 
normalizable  and  [a' /a\r  is  strongly  normalizable.  Therefore,  t  is  also  strongly  normalizable. 

We  will  induct  over  len  =  iAt)  +  u(t\  ).  We  will  prove  that  for  all  values  of  len,  the  type 
(Aa:  [k/J\ki .  t)  ti  always  reduces  to  a  type  that  belongs  to  SK2[C/j\,  given  that  t\  G  SK1  [C/J\ 
and  [ti/o\t  G  SK2\C/j], 

•  len  =  0  There  are  two  possible  reductions.  A  beta  reduction  yields  [ti/ccJt  which  by 
assumption  belongs  to  SK2  \Cfj\ .  If  t  =  To  a  and  a  does  not  occur  free  in  To,  then  we  have 
an  eta  reduction  to  to  ti.  But  in  this  case  [t\/cx\t  =  tqT\. 

•  len  =  k  +  1  For  the  inductive  case,  assume  that  the  hypothesis  is  true  for  len  =  k.  There 
arc  two  additional  reductions.  The  type  t'  can  reduce  to  (Aa :  [n/fm  .  t)  t'{  where 

Ti  t".  By  property  2  of  definition  A.2.6,  t"  belongs  to  <SKl  [C /J\.  Therefore,  [t'//o\t 
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belongs  to  SK2[C/J ].  Moreover,  lev  =  k.  By  the  inductive  hypothesis,  ( A  a :  n  i .  r)  t” 
always  reduces  to  a  type  that  belongs  to  SK2[C  /~j\.  By  property  3  of  definition  A.2.6, 

(Act :  ki  .  t)  t'(  belongs  to  SK2  [Cfj] . 

The  other  reduction  of  r'  is  to  (Act:  t")  t\  where  r  t" .  By  lemma  A.2.2, 

[ri/ct]r  [ti/o\t" .  By  property  2  of  definition  A.2.6,  [t\/q\t"  G  SK2[C/J ].  Moreover, 
len  =  k  for  the  type  t' .  Therefore,  by  the  inductive  hypothesis,  (Act:  [k/J\k  \  .  t")  t\  always 
reduces  to  a  type  that  belongs  to  SK2  [C j  j].  By  property  3  of  definition  A.2.6, 

(Act :  \k/ j]n\.  t")  n  belongs  to  SK2[C/j], 

Therefore,  the  neutral  type  t'  always  reduces  to  a  type  that  belongs  to  SK2  [C / j ].  By  property  3  of 
definition  A.2.6,  t'  G  SK2[C/j],  Therefore,  Act:  \K/ j\n\.  r  belongs  to  SKl[C/j]  —  SK2[C/j],  This 
implies  that  Xa:  [k/J\ki.  t  belongs  to  SKl^K2[C/J ].  □ 

Lemma  A.2.19  V  G  5Vj. 

Proof  This  is  true  if  for  any  kind  V  [[k/,7’]k:i]  G  S^^q\^q[C,Ck1/ j,j].  This  implies 

that 

g  Sj^n\C,CK1/j,  j]  -v  Sn\C,CK1/j,j } 

This  is  true  if  for  all  r  G  Sj^ci[C,CK1/j,  j],  it  is  true  that  V  [[k/J]«i]  t  G  Sn[C,CK1/j,j].  This  in 
turn  implies  that  ¥  [[k/j]ki]  t  G  Rci-  This  is  true  if 

Typerec[[7c/j]K]  (V  [[Tc/jJki]  t)  of  (rjnt;  r^;  ry;  t^h-)  belongs  to  5K[C/j]  is  true  with  the 
conditions  in  proposition  A.2. 15.  Since  each  of  the  types  r,  Tjnt,  r_^,  7y,  and  u  belongs  to  a 
candidate,  they  are  strongly  normalizable.  We  will  induct  over 

len  =  v(t)  +  v{Tmt)  +  v{t-,)  +  zc(ry)  +  v(tv f).  We  will  prove  that  for  all  values  of  len,  the  type 
Typerec[[7c/j]K]  (V[[k/J]ki]  t)  of  (rint;  r^;  rv;  ny)  always  reduces  to  a  type  that  belongs  to 
SK[C/j\;  given  that  r  G  Sj->n[C,CK1/j,  j],  and  rint  G  SK[C/J],  and  G 

and  ry  G  .  (j_>f2)— >(j— >k)— >kP/j],  ¥¥  ¥  <5(yj.  n)_ >(Vj. «)— ►kIZ-'/j]- 

Consider  t'  =  Typerecp/j]K]  (V  [[k/j]ki]  r)  of  (rint;  r_;  rv;  r^) 

•  /en  =  0  Then  the  only  possible  reduction  of  t'  is 

t[  =  rv  [[7Z/j]Ki\  t  (Aa:[K/j]/ci.Typerec[[7c/j]K]  ra  of  (rint;  r_^;  rv;  r^)) 
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Consider  t"  =  Typerec[[K/y]/.']  r  a  of  (rint;  r_>;  rv;  r^r).  For  all  t\  G  CK1,  the  type 
[ti/q]t"  reduces  to  the  type  Typerec[[K/y]ft]  tt\  of  (rint;  r_^;  rv;  r^-).  By  assumption,  r 
belongs  to  Sj[C,CKl/j,  j]  —>  S<>\C.CKl/j,j}.  Therefore,  r  belongs  to  CKl  ->  R<>  which 
implies  ttj  6  Ao.  Therefore  Typerec[[«/y]K]  tti  of  (rint;  r__;  rv;  r^-)  belongs  to 
<SK[C /y].  Therefore,  by  lemma  A.2.18,  (replacing  SKl\C fj\  with  CKl  in  the  lemma), 

Xa:  [k/j]«i.  Typerec[[K/j]/«]  ra  of  (Tint;  r_^;  rv;  r^)  belongs  to  *  Sk  [C/j]. 

By  assumption,  rv  belongs  to  SVy.  P/J]  • 

Therefore,  rv  [[a«/j]k-i]  belongs  to  CKl/j,j}.  This  implies  that 

W  [[k/j> i]  T  belongs  to  S{j^K)^K[C,  CKl/j,j\. 

Consider  C  =  Srj^K)^K[C,CKl/j,j].  Then  C  is  equal  to 
Sj^K[C,CKl/j,j]  ->  SK[C,CKl/y,  j].  This  is  equivalent  to 

(CK1^SK[C,CK1/j,j])^SK[C,CK1  /y,y].  But  j  does  not  occur  free  in  n.  So  the  above 
can  be  written  as  ( CKl  —>  SK[C/J | )  — >  SK [C  fj] .  This  implies  that  t[  belongs  to  SK [C ,/y] . 

•  len  =  k  +  1  The  other  possible  reductions  come  from  the  reduction  of  one  of  the  individual 
types  r,  rint,  r_^,  ry,  and  u,  The  proof  in  this  case  is  similar  to  the  proof  of  the 
corresponding  case  in  lemma  A.2.16. 

Since  t'  is  neutral,  by  property  3  of  definition  A.2.6,  r'  belongs  to  SK  [C / y ].  □ 

Lemma  A.2.20  If  for  every  kind  rf  and  reducibility  candidate  C  of  this  kind, 

W/j']r  G  SK[C,C'/j,j'],  then  Ay7.  r  G  Syf_K[C/j]. 

Proof  Consider  the  neutral  type  t’  =  (A/,  r)  [«/]  for  an  arbitrary  kind  n1 .  Since  \j" /j']r  is 
strongly  normalizable,  r  is  strongly  normalizable.  We  will  induct  over  len  =  iAt).  We  will  prove 
that  for  all  values  of  len ,  the  neutral  type  (A y7.  r)  [«/]  always  reduces  to  a  type  that  belongs  to 
SK[C,C'/J,j'};  given  that  [rf  /j']t  G  Sk  [C ,  C'/J. ,  f] . 

•  len  =  0  There  are  two  possible  reductions.  A  beta  reduction  yields  f  / j']r  which  by 

assumption  belongs  to  C' /j,f].  If  r  =  tq  [y7]  and  y7  does  not  occur  free  in  ro,  then  we 

have  an  eta  reduction  to  ro  [«/].  But  in  this  case  [n' /j']r  =  ro  [«/]. 

•  len  =  k  +  1  For  the  inductive  case,  assume  that  the  hypothesis  is  true  for  len  =  k.  There  is 

one  additional  reduction,  (Ay7,  r)  [/r/]  (Ay7,  ri)  [n'}  where  r  t\.  By  lemma  A.2.3, 
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we  know  that  [d / j']r  ^  [n1  /j']r\  .  By  property  2  of  definition  A.2.6, 

W/j']n  £  SK[C,  C'/j,f].  Moreover,  lev  =  k  for  this  reduct.  Therefore,  by  the  inductive 
hypothesis,  (A j' .  ri)  [k/]  always  reduces  to  a  type  that  belongs  to  SK [C .  C' /j,j'}.  By 
property  3  of  definition  A.2.6,  (A  j' .  ri)  [«/]  belongs  to  SK[C,C' /j,f]. 

Therefore,  the  neutral  type  t1  always  reduces  to  a  type  that  belongs  to  SK[C ,  C / j ,j'\.  By  property 
3  of  definition  A.2.6,  t'  G  SK\C,C' /j,  j'].  Therefore,  A  j'.  r  belongs  to  Sw.K[C/j\.  □ 

Lemma  A.2.21  Ifr  G  Syj_K[C/j\,  then  for  every  kind  \k/j\k!  t  [[k/j]*/]  G  S[k'  /  jflC  /  j\- 

Proof  By  definition,  r  \[n/j]n'}  belongs  to  SK{C.  C' / j,j\,  for  every  kind  \K/ j]n'  and  reducibility 
candidate  C'  of  this  kind.  Set  C'  =  SKi[Cfj\.  Applying  lemma  A.2.14  leads  to  the  result.  □ 

Lemma  A.2.22  V+  G  <S(Vj.  ci)^n\C/j\. 

Proof  This  is  true  if  for  all  r  G  S-/h  <_>  [C /j] ,  we  have  v'r  G  Rq.  This  is  true  if 

Typerec[7r/j]K]  (V+r)  of  (rint;  r_>;  ry;  t  R  belongs  to  SK[C/J]  with  the  conditions  in 

proposition  A.2. 15.  Since  all  the  types  arc  strongly  normalizable,  we  will  induct  over 

len  =  v(t)  +  z'(Tint)  +  z/(r-*)  +  ^(tv)  +  n(rv r).  We  will  prove  that  for  all  values  of  len,  the  type 

Typerec[|K/.7]K]  (V+r)  of  (rint;  r_^;  ry;  r^)  always  reduces  to  a  type  that  belongs  to  SK[C/J]; 

given  that  r  G  SWj,n[C/J\,  rint  G  SK[C/j],  r G  Sq^q^k^k^k[C /J\, 

ty  G  SVj,  (j — >n) — >(j — >k) — and  G  S(\/j . n)_»(Vj .«)_»«; [f-'/j]-  Considei 

t'  =  Typerec[[7c/j]K,]  (V+r)  of  (rint;  r^;  rv;  r^) 

•  len  =  0  Then  the  only  possible  reduction  of  t'  is 

Vr(Aj.Typerec[[K/j>]  (r[j])  of  (rint;  r_^;  rv;  v)) 

Consider  t"  =  Typerec[[K/j]  k]  (r  [j])  of  (rmt;  r_;  ry;  G/i  )■  For  an  arbitrary  kind  k\ 

W/j ]r"  is  equal  to  Typerec[[K/j]ft]  r  [«/]  of  (rint;  r^;  ry;  r^r).  By  the  assumption  on  r, 
we  get  that  r  [«/]  G  Ao.  Therefore,  by  definition,  \n'  /j]r"  G  5k[C/j].  Since  j  does  not 
occur  free  in  rt,  we  can  write  this  as  [«/ /j}r"  G  SK  [C .  C' /j,j\  for  a  candidate  C  of  kind  n' . 
By  lemma  A.2.20  A  j.  Typerec[[K/j]K]  (r  [j])  of  (Tjnt;  r_^;  ry;  tv f)  belongs  to  Syj.K{C/j]. 
By  the  assumptions  on  t:/  and  r,  Vr(Aj.Typerec[«]  (r[j])  of  (rint;  r_^;  rv;  r^)) 
belongs  to  SK[C/j]. 
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•  len  =  k  +  1  The  other  possible  reductions  come  from  the  reduction  of  one  of  the  individual 
types  r,  Tjnt,  r_^,  ry,  and  t.,  .  The  proof  in  this  case  is  similar  to  the  proof  of  the 
corresponding  case  in  lemma  A.2.16. 

Since  t'  is  neutral,  by  property  3  of  definition  A.2.6,  t'  belongs  to  SN [C /J\.  □ 

We  now  come  to  the  main  result  of  this  section. 

Theorem  A.2.23  (Candidacy)  Let  r  be  a  type  of  kind  n.  Suppose  all  the  free  type  variables  ofr 
are  in  ct\  . . .  an  of  kinds  n  \  ...  k„  and  all  the  free  kind  variables  of  n,  K\  ...  Kn  are  among 
j i  . . .  jm.  If  Ci . . .  Cm  are  candidates  of  kinds  k\  . . .  n'm  and  n  . . .  rn  are  types  of  kind 
[k'/J\ki  . . .  [n’ fj\nn  which  are  in  SKl[C/j }  . . .  SKn[Cfj\,  then  [n' /J\t[t /a]  belongs  to  SK[C/J ]. 

Proof  The  proof  is  by  induction  over  the  structure  of  r. 

1.  The  cases  of  int,  — V,  V+  are  covered  by  lemmas  A.2.16  A.2.17  A.2.19  A.2.22. 

2.  Suppose  r  =  ay  and  k  =  Kt.  Then  [k' /J]t[t /a]  =  Ti.  By  assumption,  this  belongs  to 

SKi[C/j\- 

3.  Suppose  t  =  t[  t!2-  Then  t[:k'  —>  k  for  some  kind  k'  and  t'2  :  n' .  By  the  inductive 
hypothesis,  [k1 /J\ r[[r/a]  belongs  to  SKt^K[C[J\  and  [n'  /’Jlr'ffr /a]  belongs  to  SK/[C/J ]. 
Therefore,  ([/V/j] r([r/a])  ( [«' 1  fj\ t'2 [t /a] )  belongs  to  SK[C/J |. 

4.  Suppose  t  =  t'  [k/].  Then  t'  :  Vji .  k\  and  n  =  [k! /j\\n\.  By  the  inductive  hypothesis, 

[n'  /  j]r' \f  /a\  belongs  to  S\/3x,Kl  [C/j\.  By  lemma  A.2.21  [nf  /  fr'  \f  /a]  \[k'  /  j]n']  belongs  to 
sW/h\K^/j]  which  is  equivalent  to  SK[C/j], 

5.  Suppose  r  =  Typerec[/i]  t'  of  (Tint;  r_^;  7y;  r^r).  Then  t'  :  (2,  and  and 

r_^ :  (2  — >12— >  k  — >  k  — >  n,  and  Ty :  Vj.  ( j  — >  (2)  — >  ( j  — >  k)  — >  n,  and 

Tyf :  (Vj.  (2)  — ■>  (Vj.  k)  — ■>  k.  By  the  inductive  hypothesis  [k1  /j]r' [r/a]  belongs  to  Rn,  and 
W /j]T,nt[r/a]  belongs  to  SK{C/j],  and  f  / j]t^[t /a]  belongs  to  Sn^n-^K-,K-^K[C/j],  and 
W/J\MTM  belongs  to  5Vj.  /J\,  and  [k'/j\- v[r/a]  belongs  to 

S(yj.  Q)^(yy  K)^K\C/J\.  By  definition  of  Rn, 

Typerec[[ft'/j]K]  W /J}t'[t/c(]  of 

[r/a];  [k' /]\t^[t /a]\  [k' /j]tv[t /a\;  \n' fj\ r^fr/a]) 
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( context )  C  ::=  []  |  A j.C  \  C[n]  |  A a:n.C  \  Ct  \  tC 
|  Typerecf/r]  C  of  (rint;  r^;  rv;  v) 

|  Typerec[K]  r  of  (C;  r_^;  rv;  r^) 

|  Typerec[K]  r  of  (rint;  C;  rv;  r^) 

|  Typerec[K]  r  of  (rint;  r_^;  C;  r^) 

|  Typerec[K]  r  of  (rint;  r_^;  rv;  C) 

Figure  A.6:  Type  contexts 


belongs  to  SK[C/J\. 

6.  Suppose  r  =  Aa/ :  n' .  T\ .  Then  t\  :  k"  where  the  free  type  variables  of  T\  are  in 

Q:„ ,  o'  and  n  =  n'  — >  k".  By  the  inductive  hypothesis,  [n' / j\r\  [t.  t' /a,  a'}  belongs 
to  SKn[C/J |  where  t'  is  of  kind  [k1  /J]k'  and  belongs  to  SKt[Cfj ].  This  implies  that 
[r'/oi']{  [k'/j\ti[t/  a])  (since  a'  occurs  free  only  in  ti)  belongs  to  SK" \C /J] .  By 
lemma  A.2.18,  A  a' :  [k' / j]n' .  ([K'/j]ri[r/a])  belongs  to  cv^K»[C/j]. 

7.  Suppose  r  =  A  j' .  t'  .  Then  t'  :  n"  and  k  =  V/.  k"  .  By  the  inductive  hypothesis, 

[k' .  k' /j,j']T'\r/a\  belongs  to  SK"[C,C' /j,j'}  for  an  arbitrary  kind  k'  and  candidate  C  of 
kind  k’ .  Since  j’  occurs  free  only  in  r',  we  get  that  [n' / j']([n' /J\t'[t /a])  belongs  to 
SKlr\C,C'fj,j'].  By  lemma  A.2.20,  A  j' .  ([k1  /]}t’[t/ a})  belongs  to  Sy?'.K"[C/J I- 

□ 

Suppose  SNi  is  the  set  of  strongly  normalizable  types  of  kind  nt. 

Corollary  A.2.24  All  types  are  strongly  normalizable. 

Proof  Follows  from  theorem  A.2.23  by  putting  C,  =  SNi  and  =  o-,.  □ 

A.3  Confluence 

To  prove  confluence  of  the  reduction  in  the  type  language  of  Xf,  we  first  define  the  compatible 
extension  i— r  of  the  one-step  reduction  Let  the  set  of  type  contexts  (ranged  over  by  C)  be 
defined  inductively  as  shown  in  Figure  A.6.  A  context  is  thus  a  “type  term”  with  a  hole  [];  the 
term  C  [r]  is  defined  as  the  type  obtained  by  replacing  the  hole  in  C  by  r. 
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Definition  A.3.1  t\  t—>  72  iff  there  exist  types  t[  and  t'2  and  a  type  context  C  such  that 
T\  —  C  [t{],  t-2  =  C  [r'ff  and  t[  t'2. 

Let  as  usual  i— denote  the  reflexive  and  transitive  closure  of  t—r. 

Lemma  A.3.2  (/Y  >—  t' ,  then  C  [r]  i— »  C  [t']. 

Proof  From  compositionality  of  contexts,  i.e.  since  for  all  contexts  C\  and  62  and  types  r, 

Ci  [C'2  [r]]  =  C  [r]  for  some  context  C,  which  is  constructed  inductively  on  the  structure  of  Cj .  □ 

Corollary  A.3.3  If  r  1— *■*  t' ,  then  C  [r]  1— ►*  C  [t'\. 

The  following  lemmas  arc  proved  by  induction  on  the  structure  of  contexts. 

Lemma  A.3.4  //tih  t-i,  then  [t/o\ti  i-r  [t/o\t2- 

Proof  sketch  Follows  from  Lemma  A.2.2.  □ 

Lemma  A.3.5  If  T\  t-i,  then  [n/j\r 1  i-r  [k/j\t2. 

Proof  sketch  Follows  from  Lemma  A.2.3.  □ 

Lemma  A.3.6  If  £ ;  A  \~  C\t]  :  n,  then  there  exist  £',  A',  and  tf  such  that  £':  A'hr  :  n'; 
furthermore,  if  £'\  A' hr'  :  k',  then  £;  A  F  C  [r7]  :  k. 

By  induction  on  the  structure  of  types  we  prove  the  following  substitution  lemmas. 

Lemma  A.3.7  If£\  A ,a:n'  \~  t  :  k  and  £;  A  F  t'  :  k',  then  £;A\~  [r'/a]r  :  k. 

Lemma  A.3.8  If£,j;A  F  r  :  n  and  £  F  tf ,  then  £]  A[k! /j\  F  [C / j]r  :  [k! / j]n. 

Now  we  can  show  subject  reduction  for 

Lemma  A.3.9  If£ ;  AFr  :  k  and  r  t’  ,  then  £]  A  Ft'  :  k. 

Proof  sketch  Follows  by  case  analysis  of  the  reduction  relation  and  the  substitution 
Lemmas  A.3.7  and  A.3.8.  □ 

Then  we  have  subject  reduction  for  r->asa  corollary  of  Lemmas  A.3.9  and  A.3.6. 

Corollary  A.3.10  If  £ ;  A  F  r  :  k  and  r  1— ►  t',  then  FAFr'  :  n. 
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For  our  confluence  proof  we  need  another  property  of  substitution. 


Lemma  A.3.11  If  t\  i-r  r2,  then  [t\/o/\t  i-r*  [72/ajT. 

Proof  The  proof  is  by  induction  on  the  structure  of  r.  The  cases  when  t  is  a  constant,  r  =  a,  or 
t  =  6  f  a,  arc  straightforward. 

case  r  =  A  j.  t'\  Without  loss  of  generality  assume  that  j  is  not  free  in  n,  so  that 
[ri/ajr  =  A  j.  ([n/ajr');  then  by  subject  reduction  (Corollary  A.3.10)  j  is  not  free  in  T2,  hence 
[t2/q]t  =  A  j.  ([r2/a]r').  By  the  induction  hypothesis  we  have  that  [t\/o\t'  i-r*  Then 

by  Corollary  A.3.3  for  the  context  A  j.  []  we  obtain  A  j.  ([ri/o']r/)  h- r*  A  j.  {[t2/(x\t'). 

The  cases  of  t  =  t'  [k]  and  r  =  A/3 :  k.  t'  are  similar, 
case  t  =  t' t":  By  induction  hypothesis  we  have 

(1)  [n  /a]r'  h-C  [t2/o\t' 

(2)  [ti/i a]r"  h-C 

Using  context  []  ([ri/a]r//),  from  (1)  and  Corollary  A.3.3  it  follows  that 

[ti/q]t  =  ([ri/a]r')  ([ri/a]r")  h-C  (^/ajr')  ([ri/ajr"); 
then  using  context  ([T^/ajr')  [],  from  (2)  and  Corollary  A.3.3  we  have 

(N/aJr')  ([ri/a]r")  h->*  (^/ajr')  ((^/ajr"))  =  [r2/a]r 
and  the  result  follows  since  i— is  closed  under  transitivity. 

The  case  of  r  =  Typerec[/i]  t'  of  (rint;  r_^;  ry;  rv f)  is  similar.  □ 

The  next  step  is  to  prove  local  confluence  of  the  reduction  of  well-formed  types. 

Lemma  A.3.12  If  £ ;  Ahr  :  kq  ,th  t\,  and  r  >  T2,  then  there  exists  tq  such  that  n  i— ro 

and  72  i— r*  ro- 

Proof  The  proof  proceeds  by  induction  on  the  structure  of  the  derivation  of  £;  A  F  t  :  kq.  For 
the  base  cases,  corresponding  to  r  being  one  of  the  O  constructors  or  a  type  variable,  no  rules  of 
reduction  apply,  so  the  result  is  trivial.  For  the  other  cases,  let  Cx,  C2,  r{,  t2,  r",  and  t”  be  such 

that  t  =  Ci  [r{]  =  C2  [t'2],  n  =  Cx  [if],  r2  =  C2  [t%],  and  if,  t'2  ^  t2. 
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case  r  =  A  j.  t'\  An  inspection  of  the  definition  of  contexts  shows  that  the  only  possible  forms  for 
C\  and  C'2  arc  [  ]  and  A  j.  C.  Thus,  accounting  for  the  symmetry,  there  arc  the  following  three 
subcases: 

•  Both  C\  and  C'2  arc  [].  The  only  reduction  rule  that  applies  then  is  7/2 ,  so  n  =  72. 

•  C\  =  A  j.  C\  and  C'2  =  A  j.  C'2.  Then  the  result  follows  by  the  inductive  hypothesis  and 
Corollary  A.3.3. 

•  A'i  =  []  and  C'2  =  A  j.  C'2.  Again,  the  only  reduction  for  t{  is  7/2,  so  r’  =  t"  [j]  for  some 
t" .  Then  there  arc  two  cases  for  t2.  First,  if  C2  =  [],  then  t2  =  t',  and — by  inspection  of 
the  rules — in  the  case  of  kind  application  the  only  possible  reduction  is  via  fa,  hence 

t"  =  A f .  t"'  for  some  j1  and  t1".  Representing  the  reductions  diagrammatically,  we  have 
immediate  confluence  (up  to  renaming  of  bound  variables): 


A/-  r'"  =a  Aj.  \j / j'}r'" 


The  second  case  accounts  for  all  other  possibilities  for  C2  (which  must  be  of  the  form 
C'2  [j])  and  reduction  rules  that  can  be  applied  in  r"  =  C2  [t2]  to  reduce  it  (by  assumption) 
to  C'2  [t2  ],  which  we  denote  by  Tq  .  The  dashed  aixows  show  the  reductions  that  complete 
local  confluence. 


A  J.(r"[j]) 


case  t  =  t1  [k]  :  Again  by  inspection  of  the  rules  we  have  that  the  contexts  arc  either  empty  or  of 
the  form  C  [k]  .  The  symmetric  cases  arc  handled  as  in  the  case  of  kind  abstraction  above.  The 
interesting  situation  is  when  C\  =  []  and  C'2  =  C2  [k]  .  The  only  reduction  rule  that  applies  for  n 
is  then  P2,  hence  t'  =  A  j.  t"  for  some  j  and  t"  .  Again  we  have  two  major  cases  for  T2:  first,  if 
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C2  =  [],  only  7)2  applies,  so  t"  =  r'"  [j]  for  some  t'" ,  thus 


(A  j.r'"\j})[K] 


WjW"  [j]  =  r'"  [«] 


In  all  other  cases  we  have  C'2  =  A  j.  C2,  so  t"  =  C2  [t2]  t— r  C"  [t2\  ;  letting  Tq  stand  for  the  latter, 
we  have  the  diagram 


(A  j.T")[K] 

fh  T 


[«/jK 


(A  j.T$)[K] 


Lemma  A.3.5^  .  ,  ^ 


[«/jK 


case  r  =  Xot.k.t':  The  contexts  can  be  either  empty  or  of  the  form  A  a :  n.  C.  The  symmetric 
cases  arc  similar  to  those  above.  In  the  case  when  C\  =  []  and  Co  =  Xa:  k.  C2 ,  the  only  rule  that 
applies  for  the  reduction  of  t[  is  rj i,  so  t1  =  r"  a  for  some  t" .  Again,  there  arc  two  cases  for  t2: 
First,  if  C2  =  [],  we  have  t’2  =  t’  =  t"  a,  and  the  only  reduction  rule  for  application  is  (3\,  hence 
t"  =  A  a' :  C .  t'"  for  some  a',  C .  and  r'" .  Since  £;  A  F  r  :  kq,  the  subterm  (Aa7 :  C .  r'")  a  must 
be  well-typed  in  an  environment  assigning  kind  k  to  a,  hence  k'  =  k,  so  that 


Acr :  k.  ((A a' :  k.  t'")  a) 

< 

A  a' :  k.  t'"  =Q  Act :  n.  [cr/c/jr" 
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In  all  other  cases  for  C2  (which  arc  of  the  form  C”  a),  we  have  t"  =  C”  [rf  i— >  C”  [rf]  ;  denoting 
the  latter  type  by  rf,  we  obtain 


T 


// 


A  a :  k.  (t"  a) 


case  t  =  t' t":  There  are  three  possibilities  for  the  contexts  C\  and  C2 :  to  be  empty,  of  the  form 
C  t’ ,  or  of  the  form  r  C.  The  symmetric  cases  proceed  as  before. 

When  C\  =  C\  r"  and  Co  =  r'  C2 ,  the  redexes  in  rf  and  t2  are  in  different  subterms  of  the  type, 
hence  the  reductions  commute:  we  have  C[  [rf]  =  t'  and  C2  [r^]  =  t",  therefore 
n  =  {C[  [rf])  (C’2  [t'2])  and  r2  =  (C[  [rf])  ( C'2  [rf]),  which  both  reduce  to  (C[  [rf])  (1 C'2  [rf]). 
When  C]  =  []  and  C'2  =  C2  t" ,  the  only  reduction  rule  that  applies  for  rf  =  r'  r"  is  T] .  hence 
t'  =  Aa  :  n.  t'"  for  some  a,  k,  and  t'" .  As  before,  there  are  two  cases  for  C2.  If  it  is  empty,  then 
the  only  reduction  rule  that  applies  to  r.f  =  t'  is  ?/i ,  hence  r'"  =  tiv  a  for  some  tiv  ,  and  local 
confluence  follows  by 

(Acr:  k.  ( tiv  a))  r" 

Vl 

tiv  t" 

Alternatively,  C2  must  be  of  the  form  Aa :  k.  C2,  where  C"2  [rf  =  t'" .  Then  t'"  1— >  C2  [rf ]  =  rff 
and  we  have 

(Aa: k.  t"')  t" 

[t"/o\t'"  (Aa: k.  rf')  t" 

Lemma  A.3?4\  .  .  ^  ^  Q\ 

[r"/aK 

When  C\  =  []  and  C2  =  t'  C2,  again  the  only  reduction  rule  that  applies  for  rf  =  t' t"  is  d\ ,  so 
t'  =  Aa:  k.  t'"  for  some  a,  k.  and  t'"  .  This  time,  regardless  of  the  structure  of  C2,  we  have  that 
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T"  =  C''[r']^C''[r"]^r",  hence 


(\CC.K.  t'")  t" 

[ r"/a]Tm  (A  cc.k.t'")^ 

Lemma  A. 3. 'll \  ^  ^ 

K/aV 

case  r  =  Typerec[/>]  r'  of  (rint;  t_>;  ry;  r,y):  The  contexts  can  be  empty  or  of  the  forms 

Typerec[/i]  C  of  (rint;  r_>;  rv;  ry) 

TyperecfK]  t’  of  (C;  r_»;  tv;  ry) 

Typerec[fi]  t'  of  (rint;  C;  rv;  ry) 

TyperecfK]  r'  of  (rint;  r_y  C;  ry) 

Typerec[K]  r'  of  (rint;  r_y  rv;  C) 

The  symmetric  cases  and  the  non-overlapping  cases  are  handled  as  before.  Accounting  for  the 
symmetry,  the  remaining  cases  are  when  C\  =  []  and  C2  is  not  empty.  Then  the  reduction  rule  for 
t\  must  be  one  of  t\,t2,  H .  and  £4.  Since  there  is  no  rj  rule  for  Typerec,  the  proofs  are 
straightforward. 

subcase  t\\  then  t'  =  int.  The  result  of  the  reduction  under  C'2  is  ignored  and  local  confluence  is 
trivial,  unless  C'2  =  Typerec[/i]  t'  of  (C"2\  r^;  ry;  ry).  In  the  latter  case, 


Typerec[K]  int  of  (rint;  r_>;  rv;  ry) 


rint 


Typerec[K]  int  of  (r/y  r_y  rv;  ry) 


T  ^  *1 

tL 


subcase  £2 :  then  t'  =  t"  — >  t'" .  We  will  use  Typerec[/;]  t'  of  r  as  a  shorthand  for 
Typerec[/,]  t'  of  (rint;  r_, :  ry;  ry),  and  similarly  for  contexts.  If  C'2  =  Typerec|y]  C'2  of  r,  then 
there  are  two  subcases  for  C2  (which  must  have  the  —  constructor  at  its  head).  Thus,  if 
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Ck  =  C: 


//  „  _/// 


Typerec[/r]  (r 

t_»  t"  (Typerecf^]  t"  of  r) 

t'"  (Typerec[/.]  t'"  of  r 

\ 

\ 

Lemma  A.3. 11  x 


Typerec[K]  (tq 


/ 

/ 

y  t2 


A  A 

r("  (Typerec[K]  r("  of  r) 
t"’  (Typerec[/,]  t'"  of  r) 


r"')  of  r 


where  t"  =  Cf  [r^]  i— ►  C2  [r"  ]  =  Tg.  The  case  of  C2  =  t"  — >  C2  is  similar. 

Of  the  other  cases  we  will  only  show  the  reduction  in  the  position  of  r_>,  writing  tq  for 
(Tint;  r_^0;  TV;  Tyf ),  where  r_^  i-r  r_^0- 


Typerec[K]  (r"  — »  t’”)  of  r 

\  t 

t — r"  (Typerec[K]  r"  of  r 


t'"  (Typerec[K,]  t'"  of  r) 

\ 

\ 

Lemma  A.3. 11  v  . 


Typerec[K]  (t"  — >  r"')  of  r0 


/ 

.  /  ^2 


r_^0  t"  (Typerec[K]  r"  of  r0) 
t'"  (Typerec[K]  t'"  of  7^) 


subcases  Fj  and  £4  are  similar  to  t-2- 

Corollary  A.3.13  If  £;  A  h  t  :  k,  t  h- r*  z/,  and  r  t—r*  t',  then  t'  h- r*  7/. 

Theorem  A.3.14  If  £;  A  b  r  :  re,  z/zctz  there  exists  exactly  one  v  such  that  th*  //. 
Proof  From  Corollaries  A.2.24  and  A.3.13. 


□ 


□ 
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Appendix  B 


Formal  Properties  Of 


In  this  chapter  we  prove  the  soundness  of  Aqc  that  we  defined  in  Chapter  4.  Throughout  this  chap¬ 
ter,  we  assume  unique  variable  names.  Our  environments  arc  sets  with  no  duplicate  occurrences 
and  no  ordering.  It  is  easy  to  show  by  induction  over  judgments  that  extending  environments  with 
additional  bindings  is  safe.  We  will  assume  this  in  the  rest  of  the  chapter. 

Definition  B.0.15  The  judgment  h  (M,  e)  says  that  the  machine  state  (M,  e)  is  well-formed.  It  is 
defined  by: 

h  M  :  'h  fit;  Dom(^f);  •;  •  h  e 
l-(M,e) 

Contrary  to  the  other  environments,  T  is  not  explicitly  constructed  in  any  of  the  static  rules, 
since  it  reflects  dynamic  information.  Instead,  the  soundness  proof,  or  more  specifically  the  type 
preservation  proof,  needs  to  construct  some  witness  flC  for  the  new  state  (M',  e’)  based  on  the  T 
of  the  initial  state  ( M ,  e). 

The  code  region  cd  is  always  implicitly  paid  of  the  environment.  We  treat  it  as  a  constant  region. 
Even  when  the  environment  is  restricted  to  a  particular  set,  say  fl/|e,  the  code  region  is  included 
in  the  restricted  set.  Therefore  is  equivalent  to  {cd  :  TC(j,  v\  :  TUl, . . .  uk  :  TUk}.  And 

filled  is  equivalent  to  {cd  :  Ycc|}. 

Lemma  B.0.16  IfQ',  r;  A  h  cr,  then  [z^/r*]©;  Ah  [u/r\c t  where  0',  r  =  0. 

Proof  The  proof  is  a  straightforward  induction  over  the  structure  of  cr.  □ 

Lemma  B.0.17  ([u/r}T)\etl/  =  [u/r](T\e,r) 
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Proof  The  lemma  is  proved  by  induction  over  the  structure  of  T. 


□ 


Lemma  B.0.18  If  T ;  0',  r;  A;  T  \~  op  :  a,  then 

’T;  [i//r]0;  A;  \v/r]T  h  [ v/r\op  :  [u/r\a  where  Q',r  =  0. 

Proof  The  proof  is  by  induction  over  the  structure  of  op.  Most  of  the  cases  follow  directly  by 
induction.  We  will  show  only  the  case  for  type  packages, 
case  (a  =  Ti,v  :  a 2):  We  know  that 

T';  Q  rr\  A;  T  b  (a=T\,  v  :  02)  :  3a  :  k.(T2 

This  implies  that  A  b  T\  and  T;  0',  r;  A;  T  h  v  :  [t|  /o:] a-2.  Applying  the  inductive  hypothesis  to 
the  derivation  for  v,  we  get  that 

T';  [v/r\Q\  A;  [v/r]T  h  [v/r\v  :  [tx/ a]{[v /r\a2) 

This  leads  to  the  required  result.  □ 

Lemma  B.0.19  Tf'k;  0',  r;  A;  T  h  e,  then  'T;  [i^/r]0;  A;  [v/r]Y  h  [v/r\e  where  0',  r  =  0 

Proof  The  proof  is  by  induction  over  the  derivation  of  e.  Most  of  the  cases  follow  directly  from 
the  inductive  hypothesis.  We  will  consider  only  one  case  here, 
case  only  0i  in  e:  We  get  that 


'T;  0,  r;  A;  T  h  only  0i  in  e 


This  implies  that 

'T|e1;0i,cd;A;r|01  h  e 

and  0i  C  0,r.  Suppose  r  ^  0i.  Then  r  does  not  occur  free  in  e.  Also  [u/r]Q\  =  0i-  Let 
T|01  =  Ti.  Then  we  have  that 

[i//r]r|01  =  Tx,  r2  and  Dom(Ti)  n  Dom(T2)  =  0-  Since  we  can  extend  environments,  we  get 
that 

*|ei  ;  0i,  cd;  A;  Ti,  T2  h  e.  Also  0i  C  [u/r\(@,  r ).  This  leads  to  the  required  result. 

Suppose  now  that  r  G  0i.  Suppose  that  0i  =  02,r.  Then  [i//r]0i  =  ©2,^-  Then  we  have 

that 
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^1  ©2,^)  ©2 >  a cd,  A,  r|e2,r  c 

Applying  the  inductive  hypothesis  we  get  that 

*102, A  [^/r]02,cd;  A;  [i//r]r|02)T.  h  [^/r]e 
Applying  lemma  B.0. 17  we  get  that 

^l©2,r;  [^/r]0i,cd;  A;  [v/r]T\e2tV  h  [v/r\e 
But  we  have  that  'h|e2)r-  =  vh|e2.  Moreover,  ’J/|e2)i,  =  'h|e2,  'h/.  Therefore,  we  get  that 

^\e2y,  [z7r]0i,cd;  A;  W/r]T\e2tU  h  [u/r\e 

We  also  have  that  [u/r]Q i  C  [v/r\Q.  This  leads  to  the  required  result.  □ 

Lemma  B.0.20  TjfA,  a:  n'  F  r  :  k  and  Ah  t'  :  k1 ,  then  A  h  [r'/ajr  :  k 

Proof  The  proof  is  a  straightforward  induction  over  the  structure  of  r.  □ 

Lemma  B.0.21  IfQ;  A,  cr :  k  h  a  and  A  h  r  :  k,  then  0;  A  h  [r/a]cr 

Proof  The  proof  is  again  a  straighforward  induction  over  the  structure  of  a.  □ 

Lemma  B.0.22  Tjf'F;  0;  A,  a  :  K]  T  h  op  :  cr  and  A  h  r  :  k  then 
T';  0;  A;  [r/a]T  h  [r/a]op  :  [r/a]<7 

Proof  The  proof  is  a  straightforward  induction  over  the  structure  of  op.  The  only  unusual  case 
is  when  op  =  ul.  In  this  case,  )  =  a  and  Dom(  T ) ;  •;  •  h  a.  Therefore,  the  variable  a  does 
not  occur  free  in  a  at  u.  □ 

Lemma  B.0.23  If^t;  0;  A,  a  :  k;  T  h  e  and  -  hr'  :  n  then  ;  0;  A;  [r'/a]T  h  [r'/a]e 

Proof  The  proof  is  a  straightforward  induction  over  the  structure  of  e.  The  only  interesting  case 
is  for  a  typecase  when  the  substituted  variable  is  being  analyzed. 

case  typecase  a  of  (ej;  e^;  aia2.ex;  ae-ea):  Suppose  we  substitute  the  type  t'  for  the  variable 
a.  Then  t'  can  only  be  one  of  Int,  t"  ->  0,  t[  x  t'2 ,  or  3a.r" .  For  a  Int,  we  need  to  prove  that 

'F;  0;  A;  [Int/orjT  h  [lnt/a] (typecase  a  Of  (ej;  e^;  aia2.ex;ae-e3)) 

This  implies  that  we  need  to  prove  that 
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'P:  0;  A;  [lnt/o]r  F  [lnt/o]ej 


By  definition,  we  know  that 

\P;  0;  A,  a  :fl;  [lnt/a]r  F  [lnt/a]e. 

Since  a  is  being  substituted  away,  this  leads  to  the  required  result. 

For  a  code  type  we  need  to  prove  that 

'P;  0;  A;  [ r 7  — >  0/o]r  F  [r7  — *  0/a]  (typecase  a  of  (ej ;  e^;  ai02-ex ;  ae.ea)) 

This  implies  that  we  need  to  prove  that 

\P;  0;  A;  [r7  — r  0/o]r  F  [r7  — r  0/o]e^ 

By  definition,  we  get  that  \P;  0;  A,  a  :  17;  T  F  e_>.  Substituting  for  a  and  applying  the  inductive 
hypothesis  leads  to  the  result. 

For  the  pair  type  we  need  to  prove  that 

'P;  0;  A;  [(r(  x  t'2)/oi] T  F  [(t{  x  t^/o] (typecase  a  of  (ej;  e^;  aia2.ex ;  cxe-^s)) 

This  implies  that  we  need  to  prove  that 

^;0;  A;  [(r(  x  t'2)/o\Y  F  [(r{  x  r£),  r{,  r2/a,  oi,  a2]ex 

By  definition,  we  know  that 

*;0;A  ,  o:fl,  a.\  :  fl,  02  :  F2;  [«i  x  02/o]r  F  [oi  x  0:2/0;] ex 

Note  that  the  valuables  oi  and  02  do  not  occur  free  separately  in  F.  Substituting  r\  for  o  1 ,  t'2  for 
02,  and  t\  x  t2  for  a\  x  02  leads  to  the  required  result. 

For  the  existential  type  we  need  to  prove  that 

'P;  0;  A;  [3oi.r7/o]r  F  [3oi.r7/o]  (typecase  a  of  (ej;  e^;  ai02.ex ;  ae.eg)) 

This  implies  that  we  need  to  prove  that 

*P;  0;  A;  [3oi.r7/a]r  F  [3oi.r7,  Aoi  :fi.  r'/a,  ae]es 
By  definition  we  know  that 

*P;  0;  A,  a  ae  :  17  — >  17;  [3oi.oe  oi/o]F  F  [3oi.oe  oi/o]eg 

Substituting  (Aoi :  Q.  r7)  for  ae  and  applying  the  inductive  hypothesis  we  get  that 
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'I';  0;  A,  a:  fl;  [Bai.r'/ajr  h  [3ai .t',  Aon  :  fi.  r'/a,  ae]e3 

Since  a  is  being  substituted  away,  we  can  remove  it  from  the  type  environment.  This  leads  to  the 
required  result.  □ 

Lemma  B.0.24  If  tit;  0;  A;  T,  x  :  a'  b  op  :  a  and  'T;  ©;  A;  T  b  v'  :  a' then 
4/;  ©;  A;  T  b  [v'/x\op  :  a 

Proof  The  proof  is  a  straightforward  induction  over  the  typing  derivation  for  op.  □ 

Lemma  B.0.25  If  T';  ©;  A;  T  b  v  :  a  and  ©i;  Aha  and  ©i  C  0,  then 
^leh  ©t!  A;  T 1 01  hv  :  it 

Proof  The  proof  is  by  induction  over  the  derivation  for  v.  Most  of  the  cases  follow  directly  from 
the  inductive  hypothesis.  We  will  consider  only  one  case  here. 

case  u.t:  We  have  that  ©;  A;  T  h  v.i  :  a  at  u.  This  implies  that  =  a  and  Dom  (T');  •  h 

a  at  v.  However,  by  assumption  we  also  know  that  ©i;  A  h  n  at  v.  This  implies  that  v  G  0  ] . 
This  implies  that  | (z /.£)  =  cr.  Moreover,  we  also  get  that  @i;  •  h  a  at  v.  Therefore,  we  get  that 
Dom(T'|e1);  •  h  cr  at  u.  From  here  we  get  that  'f'|e1;  ©i;  A;  TIqj  h  v.l  :  a  at  v.  □ 

Lemma  B.0.26  If' V]  0;  A;  T,  x  :  a  h  e  and  T';  ©;  A;  T  h  v  :  a  then 
'T;  0;  A;  T  h  [v/x\e 

Proof  The  proof  is  again  a  straightforward  induction  over  the  structure  of  e.  We  will  only  show 

the  proof  for  a  couple  of  cases,  the  rest  of  them  follow  similarly. 

case  only  ©i  in  e:  We  have  that 

*;0;A;r,.T  :  o  h  only  ©i  in  e.  This  implies  that 

'kle^  @i;  A;  (T,  x  :  a)  |q1  h  e.  If  we  have  that 

©i;Ah(T,  then  we  get  that 

^IqjJ  ©i;  A;  T|0j,  x  :  cr  h  e.  By  lemma  B.0.25  we  get  that 

Ik  1 0i ;  ©i;  A;  T|e1  h  v  :  a.  Applying  the  inductive  hypothesis  gives  us  that 

^ |©1 ;  ©t;  A;  r|01  h  [v/x\e. 

In  the  other  case,  we  get  that 

T|e, ;  0| :  A:  Tie,  h  e.  This  implies  that  x  does  not  occur  free  in  e.  The  required  result  follows 
from  here. 
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case  typecase  a  of  (ep  e^;  a\a2-ex ;  Oe-ea):  By  assumption,  we  get  that 
A  b  a  :  f) 

0;  A;  [lnt/a]r,  x  :  [lnt/or]cr  b  [Int/orje* 

VP;  0;  A;  T,  x  :  cr  b 

VP;  0;  A,  a\  :  oli  :  12;  [«i  x  ^/ctjr,  x  :  [op  x  a2/oi\cr  b  [op  x  a2/«]ex 

TO  0;  A,  ae  :  12  — >  12;  [3ai  .ae  a\/a]T ,  x  :  [3ai.ae  a\/a]a  b  [3a\.ae  a\/a]e^ 

By  lemma  B. 0.22,  we  know  that  if  IP;  0;  A;  T  b  v  :  a,  then 

IP;  0;  A;  [t/q\Y  b  [r /a]v  :  [r/a]<7.  Now  substitute  [lnt/a]n  in  the  e*  branch,  substitute  v  in  the 

branch,  substitute  [a\  x  a2/a]v  in  the  ex  branch,  and  substitute  \3a\.aea\/a\v  in  the  es 

branch.  The  required  result  follows  from  the  inductive  hypothesis  on  each  branch.  □ 

Proposition  B.0.27  (Type  Preservation)  If\~  (M,  e)  and  (M,  e)  ^  (M',  er)  then  b  (M',  e'). 
Proof  The  proof  is  by  induction  over  the  evaluation  relation.  We  will  consider  only  the  cases 
that  do  not  follow  directly  from  the  inductive  hypothesis  and  the  substitution  lemmas, 
case  v.I\t\[P\(v):  The  lemma  follows  from  the  fact  that  tag  reduction  is  strongly  normalizing  and 
confluent,  and  preserves  kind, 
case  v.I[t'][P\{v)\  By  definition, 

IP;  Dom(T');  •;  ■  b  vA[t']  [P\  (v) 

Since  M(v.t )  =  (A [ct  T n][r\{x  :  a).e),  we  have  that 

T';  Dom{^>)-,  •;  •  b  v.i  :  V[a  T«][r] (o') —>•  0  at  i/ 

This  implies  that 

^lcd’cd’  r;  a  :  k;  x  :  cr  b  e 

By  the  typing  rule,  we  get  that 

VP ;  Dom(^> ) ;  • ;  •  b  Uj  :  [P,  t'/t,  a] 

and  •  b  T-  :  k,.  From  lemma  B.0.19  we  get  that 

- ¥ 

VP |cc| ;  cd,  P;  A;  x  :  [P/r\c r  b  [P/r\e 

From  lemma  B. 0.23  we  get  that 

- * 

^lCd!cd>^';x  :  [v,T'/r,a\o-  b  [P,T'/r,a]e 
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Since  \F|CC|  C  \F  and  cd,  v  C  Dom(f),  we  can  extend  the  environment  for  deriving  e.  Applying 
lemma  B.0.26  we  get  that 

'F;  Dom{x F);  F  e[v,  t' ,  v/f,  t.  x\ 

which  leads  to  the  result. 

case  let  x  =  put[^]n  in  e:  By  definition, 

'h;  -Dom(’I');  •;  •  F  let  x  =  put[z/]n  in  e 

From  the  typing  rules, 

\F;.Dom(vF);-;- F  put[i/]?;  :  a  at  v 
for  some  type  a,  and  v  G  Dom(^>).  This  implies  that 

\F;  Dom(\F);  phi)  :  a 

Again,  from  the  typing  rules, 

*F,  v.l :  a;  Dom{ \F);  •;  •  F  v.l  :  a  at  v 

The  required  result  now  follows  from  lemma  B.0.26. 
case  let  x  =  get  v.l  in  e:  By  definition, 

'F;  .Dom('F);  ■;  •  h  let  x  =  get  v.l  in  e 

From  the  typing  rules  we  get  that 

\F;  Dom(\F);  ■;  ■  F  v.l  :  a  at  v 

for  some  type  a  Again  from  the  typing  rules,  we  get  that  \F {v.l)  =  o.  This  implies  that  if  M {v.l)  = 
v ,  then 

\F;  Dom(\F);  phi)  :  a 

The  required  result  follows  from  lemma  B.0.26. 
case  let  region  r  in  e:  By  definition, 

'F;  Dom(’F);  •;  •;  •  F  let  region  r  in  e 

This  implies  that 

\F;  Dom(\F),  r;  pp  he 

By  lemma  B.0.19, 
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'P;  Dom(^f),  u;  [v/r\e 


Since  v  is  a  newly  introduced  region,  we  can  extend  'P  with  it.  This  implies  that 

\P,  i — >  {};  Dom{\ P),  iq  [u/r\e 

This  is  the  required  result, 
case  only  0  in  e:  By  definition, 

*P;  Dom(’P);  only  0  in  e 

This  implies  that 

'Plejcd,  h  e 

But  cd,  0  =  Dom{\ P|©).  This  implies  that 

T'|e;Do7n(T'|e);  •;  •;  •  P  e 

which  is  the  required  result. 

For  all  of  the  typecases,  the  required  result  follows  directly  from  the  typing  rules  since  the 
value  environment  is  empty. 

Lemma  B.0.28  (Canonical  forms) 

1.  TjfvP;  0;  ■;  •;  ■  P  v  :  int  then  v  =  n. 

2.  If\ P;  hr  :  a  at  v  then  v  =  v.t. 

3.  Ifx P;  ©;•;•;•  Fn  :  a\  x  <J2  then  v  =  (vi,  V2). 

4.  If\ P;  ©;•;•;•  hr  :  3a  :  n.a  then  v  =  (a  =  T,  v'  :  a). 

5.  If\ P;  ©;•;•;•  Fn  :  V[a?  n\[r\(a)  ^  0  then  v  =  \[a?  n][r\(x  Ta).e. 

Proof  The  proof  follows  from  the  inspection  of  the  typing  rules  for  values.  □ 

Proposition  B.0.29  (Progress)  If  3  (AT  e)  then  either  e  =  halt  v  or  there  exists  a  (M',  e')  such 
that  (M,  e)  (M1 ,  e'). 

Proof  The  proof  is  again  by  induction  over  the  structure  of  e.  By  definition,  \P ;  Dom(\ P) ;  •;  •  F  e. 
The  proof  for  the  individual  cases  staid  from  this  point. 
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case  v[t}[v\{v)\  From  the  typing  rules,  v  :  V[aT K][r](a)  — >  0  at  u  By  lemma  B.0.28,  v  =  vl. 
From  the  typing  rules 

M(y.l)  =  A  [a  T  K][r\(x  T  cr).e  This  implies  that  we  have  a  reduction. 

case  let  x  =  op  in  e:  If  op  =  v,  then  we  have  a  reduction.  If  op  =  tt,?;,  then  from  the  typing  rules, 
T;  Domi,^ ) ;  •;  •  F  v  :  cr\  x  (J2.  The  required  result  follows  from  lemma  B.0.28.  In  the  case  of 
put[^]n,  the  result  follows  directly.  The  constraint  v  6  0  ensures  that  v  e  Dom(T').  In  the  case 
for  get  v,  by  the  typing  rules  we  know  that  v  =  u.t  for  some  v.l.  Again  from  the  typing  rule  we 
know  that  T'(zzT)  =  a.  This  implies  that  M(y.£)  =  v'  for  some  value  v' . 

For  the  other  cases  of  e,  the  proposition  follows  directly  from  the  operational  semantics.  □ 
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Appendix  C 


Formal  Properties  of  Xlcc 


In  this  chapter  we  prove  the  meta-theoretic  properties  of  our  type  language  X(<c.  The  proofs  are 
based  on  the  methods  in  Werner  [Wer94],  We  use  the  formalization  of  the  language  presented 
in  Section  5.4.  In  Section  C.l  we  prove  subject  reduction,  in  Section  C.2  we  prove  the  strong 
normalization,  in  Section  C.3  we  prove  the  Church-Rosser  property,  in  Section  C.4  we  prove  the 
consistency  of  the  underlying  logic. 

C.l  Subject  reduction 

The  proof  is  structured  as  follows: 

•  We  first  define  a  calculus  of  unmarked  terms.  These  arc  terms  with  no  annotations  at  lambda 
abstractions.  We  show  that  this  language  is  confluent. 

•  We  then  prove  Geuvers’  lemma  -  a  weak  form  of  confluence.  It  says  that  a  term  that  is  equal 
to  one  in  head  normal  form  can  be  reduced  to  an  //-expanded  version  of  this  head  normal 
form. 

•  From  Geuvers’  lemma,  we  arc  able  to  prove  the  inversion  lemma  which  relates  the  structure 
of  a  term  to  its  typing  derivation. 

•  We  arc  then  able  to  prove  the  uniqueness  of  types  and  subject  reduction  for  /3t  reduction. 

•  We  arc  then  able  to  prove  that  the  system  preserves  sorts  -  that  is,  if  two  terms  arc  convertible 
and  well  sorted,  then  they  have  the  same  sort. 
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•  Finally,  we  prove  the  strengthening  lemma  and  then  subject  reduction  for  rj  reduction. 

C.1.1  Unmarked  terms 

The  PTS  language  is  non-confluent.  Nederpelt  gave  the  following  counterexample  -  let  A  be  the 
term  defined  by  XX :  A\ .  (A Y  :A-2.Y)X.  Then  we  have  that  At>p XX :  A\ .  X  and  A \>v  X Y  :  A2 .  Y. 
For  our  proofs  we  want  to  operate  in  a  language  that  is  confluent.  We  will  therefore  introduce  the 
notion  of  unmarked  terms.  As  non-confluence  is  due  to  the  presence  of  type  annotations  in  A 
abstractions,  the  unmarked  terms  arc  obtained  by  erasing  the  type  annotations. 

The  set  of  unmarked  terms  ||  A  ||  are  defined  below.  We  are  given  a  marked  variable  _that  can 
not  be  used  elsewhere. 


s 


=  s 


II* 

\\A1  A2 
A  X-.Ai.A2 


=  X 

=  Mtll  \\A2 

=  XX :  _.  ||  A2 


\\UX:A1.A2 

lnd(A:Kind){A} 


n*:Mi||  .||a2|| 

lnd(Y:Kind){pjj} 


||  Ctor  (i,  Ai) 
Elim  [I,A2](A1){A} 


Ctor  (i,  ||  Ai  ||) 

Elim[||/||,  ||  A2 IIKII  A,  ||){ij"A]j} 


Lemma  C.1.1  For  all  terms  A,  B,  A',  B',  and  for  all  variables  X  and  Y,  we  have  that  [XY  : 
A'.B/X]A=(3vl  [XY:B'.B/X]A. 


Proof  Consider  A2  =  [A Z  :  A'.  ( XY:B' .  B)  Z/X\A.  Then  A2  >p  [( XZ  :  A'.  [ Z/Y]B)/X\A 
and  ,42  l>r;  [AU  :B'.B/X]A.  Alpha  converting  the  first  reduct  leads  to  the  required  result.  □ 


Lemma  C.1.2  For  all  terms  A,  we  have  A  — firi  II  A  |. 

Proof  Follows  from  lemma  C.1.1.  □ 


Definition  C.1.3  (to  reduction)  We  say  that  A  >t0  ||  A'  ||  iff  A  >t  A!  and  ||  A  ||/||  A'  |j. 

Proposition  C.1.4  For  all  terms  A  and  A’,  if  A  \>p  A',  then  ||  A  ||  t>p  ||  A'  ||  or  ||  A  ||=||  A' 
Similarly,  if  we  have  that  A  >t  A' ,  then  ||  A  ||  >t0  ||  A'  ||  or  ||  A  ||  =  ||  A'  ||.  Moreover,  if\\  A  ||  >pLo 
A!  ||,  then  there  exists  a  A"  such  that  A  >gL  A"  and  ||  A"  ||=||  A'  |. 
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Lemma  C.1.5  (Confluence  for  unmarked  terms)  For  all  unmarked  terms  ||  A  ||,  the  fipto  reduc¬ 
tion  is  confluent. 

The  proof  is  based  on  the  method  of  parallel  reductions  due  to  Tait  and  Martin-Lof. 

Definition  C.1.6  (Parallel  reduction)  Define  — »  on  unmarked  terms  as  below,  in  which  we  as¬ 
sume  that  A  — »  A' ,  B  — »  B' ,  etc: 

A^rA 
AB^r  A'  B' 

\X:_.A^\X:_.  A' 

UX:A.B  ^UX:A'.B' 

lnd(X:Kind){A}  -»•  lnd(X:Kind){I'} 

Ctor  (i,I)  — »•  Ctor  (i.  I') 

Elim[A,C'] (/){!}  -«•  E\\m[A' ,C'}{I'){A'} 

(A X:_.A)  B  [B'/X]A' 

\X:_.A  X  -»•  A!  ifX  £  FV{A) 

Elim[/,  C]((Ctor  (i, I)  B)){A}  -»  & 

where  I  =  lnd(X :  Kind){C} 

B'  =  ATT_.(Elim[/',C'](y){i'/}) 

The  parallel  reduction  commutes  with  respect  to  substitution. 

Lemma  C.1.7  If  A  A'  and  B  -«•  B',  then  [B/X]A  -«•  [B'/X]A'. 

Proof  By  induction  over  the  fact  that  A  — ^  A'.  □ 

The  parallel  reduction  also  has  the  following  properties  with  respect  to  terms  such  as  products 
and  inductive  definitions.  The  proof  in  each  case  is  immediate  and  follows  by  induction  over  the 
structure  of  the  term. 

Proposition  C.1.8  Suppose  A  =  ITT  :  B.Y  C.  If  A  can  be  reduced  to  A'  through  a  reduction 
relation  (—»,  \>q,  etc.),  then  A'  =  II X  :B' .Y  C'  where  all  the  B  and  C  can  be  reduced  to  B'  and 
C  by  the  same  reduction  relation. 
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Proposition  C.1.9  Suppose  A  =  YIX :  B.Y  C  and  A1  =  YIX  :  B' .  Y  C  be  two  terms  such  that 
both  can  be  reduced  to  A"  through  a  reduction  relation  (— \>p,  etc.).  Then  A "  =  II X :  B" .  Y  C" 
where  B  and  B'  can  be  reduced  to  B"  by  the  same  relation  and  C  and  C’  can  be  reduced  to  C"  by 
the  same  relation. 

The  parallel  reduction  is  important  because  it  subsumes  the  single  step  reduction;  that  is,  if 
A  A’ ,  then  we  have  that  A  A’  which  also  implies  that  A  t>*  A! .  From  here,  to  show  the 
confluence  of  t>,  it  suffices  to  show  the  confluence  of  parallel  reduction. 

Lemma  C.1.10  For  all  unmarked  terms  D.  D',  D" ,  we  have  that  if  D  — »  I)1  and  D  — »  D",  then 
there  exists  a  I)1”  such  that  D'  — ^  D'”  and  D"  — ^  D'". 

Proof  The  proof  is  by  induction  over  the  structure  of  D.  We  will  only  show  one  case  here. 

•  Suppose  D  =  Elimfl,  C]((Ctor  (i, /)  i?)){A}. 

-  We  can  then  have  D’  =  (<1> x,i',B’{C ■,  A'ff)  B'  and  D”  =  ,  A" ))  B" .  We 

have  that  I'  =  lnd(W  :  Kind){C''}  and  I "  =  lnd( X  :  Kind){C"}.  This  implies  that 
Ci  C\  and  C\  C'f  By  applying  the  induction  hypothesis  to  the  subterms,  we 
get  that  /'  — ^  I'"  and  I"  — »  I'"  and  so  on  for  the  other  subterms.  From  here  and 
proposition  C.1.9,  it  follows  that  we  can  take  D"'  =  ($x,r",B'(Cli11 ,  A '"))  IT”. 

-  Suppose  D'  =  Elim[/,,C"]((Ctor(i,/')  B')){A'}  and  D”  =  ($*,/ ^BfC”,A”))  Ft”. 
As  above  we  can  again  define  I'”,  C'” ,  etc.  and  take  D"'  =  fb x.j111  .iriC”' .  A'”))  B'”. 

-  Also  D'  =  Elim[//,C"]((Ctor(i,I/)  B')){A'}  and 

D "  =  Elimfl",  C"']((Ctor  ( i ,  I”)  B”)){A"}.  In  this  case,  we  can  again  take  that 
D”'  =  Elim[I///,Cw]((Ctor(i,I,,/)  B7//)){A7"}. 

□ 

As  a  corollary  of  the  confluence  of  unmarked  terms  we  get  the  following: 

Corollary  C.1.11  If  A  and  B  are  two  distinct  sorts  or  two  distinct  variables  or  a  variable  and  a 
sort,  then  we  have  that  A  f  B. 

We  will  need  another  lemma  -  that  of  the  delay  of  rj  reduction.  But  before  that,  we  have  to 
define  another  valiant  of  the  i  reduction.  This  essentially  says  that  a  i  reduction  that  would  appear 
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only  after  a  series  of  eta  reductions  can  be  reduced  straightaway  without  going  through  the  eta 
reductions.  For  well  typed  terms,  this  is  equivalent  to  t  reduction,  but  it  also  allows  us  to  retain  the 
property  of  delay  of  //  reduction  for  ill-typed  terms. 

B\m[I,A"}(\X:A>.(C\or(i,I)A)C'){B}  >t,  (d >x,iMci’Bi))  A 
where  I  =  lnd(X :  Kind){C} 

B’  =  XY:I.  (Elim[/,  A"](y){i?}) 

Cf  Xi  and  X*  f.  FV(A) )  U  FV(I) 

Proposition  C.1.12  For  all  terms  A  \  and  A2,  we  have  that  A\  =^1,  A  2  if  and  only  if  A\  =pnd  ^2- 

Lemma  C.l. 13  If  .4  [>f;  A'  0,3,/  A",  then  either  A  A",  or  there  exists  a  A’"  such  that 
A  \>pe  A!"  >*  A”. 

Proof  The  proof  is  by  induction  over  the  structure  of  A.  We  will  consider  only  the  cases  that  do 
not  follow  directly  from  the  induction  hypothesis. 

•  A  =  C  D.  There  are  two  cases. 

-  If  C  [>ri  C',  then  it  follows  immediately  from  the  induction  hypothesis. 

-  If  D  [>ri  D'  and  C  =  XX :  B.  B'  and  A”  =  [D'/X]B',  then  take  A'"  =  [D/X]B'.  The 
other  cases  follow  from  the  induction  hypothesis. 

•  A  =  AX  :  C.B  X.  Suppose  A"  =  B'  where  B  t>g,i  B' .  But  then  we  also  have  that 
A  \>ge  XX  :  C.  B'  X.  Since  the  reduction  does  not  introduce  new  free  variables,  this  term 
can  now  r/- reduce  to  If. 

□ 

Lemma  C.l. 14  (Delay  of  7/  reduction)  For  all  terms  A  and  A',  if  A\>*  A! ,  then  there  exists  a  term 
A"  such  that  A  A"  >*  A'. 

Proof  Follows  from  lemma  C .  1 . 1 3 .  □ 

We  will  next  prove  Geuvers’  lemma  which  is  essentially  a  weak  form  of  confluence.  This  is 
enough  to  prove  the  uniqueness  of  types  and  subject  reduction.  But  before  that  we  need  to  define 
the  counterpart  of  the  i1  reduction  for  unmarked  terms.  We  define  it  in  the  obvious  way 
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Definition  C.1.15  (/[,  reduction)  We  say  that  A  >,/.  ||  A'  ||  iff  A  t>(/  A'  and  ||  A  ||/||  A'  ||. 

As  before  it  has  the  following  property: 

Proposition  C.  1.16  Suppose  A  \>Lt  A1.  Then  either  ||  A  ||=||  A'  ||,  or  ||  A  ||  O,^  \\  A' \\.  Moreover, 
if\\  A  ||  ||  A!  ||,  then  A  >t/  A!. 

Lemma  C.1.17  (Geuvers  lemma) 

•  If  A  =pr]L  X  A,  then  A  \>*^,  A Y  :  A! .  ( X  B  C)  where  for  all  i,  At  =pVL  Bi  and  for  all  j, 
Cj  Yj. 

•  If  A  =(3^1  T1Al  :  A1.A2,  then  A  A Y  :  A'.  ((ILA  -.A^.A^)  B)  where  A\  =Qni  A3  and 
A2  =/V  a4  and  for  all  i,  B,  \>*  Yr. 

•  If  A  =3m  Ctor  (i,  I)  C,  then  At>*^L,XY :  A! .  ((Ctor  (i,  I')  C')  B)  where  for  all  i,  C{  =pVi  C[ 
and  for  all  j,  Bj  [>*  Yj,  and  I  =pVi  I' ■ 

•  If  A  =gVL  lnd(X  :  Kind){A}  C,  then  A  A Y  :  A! .  ((lnd(A :  Kind){A"})  Cr)  B  where 

for  all  i.  A,  =gvl  A"  and  for  all  j,  Cj  =/3Vt,  and  for  all  k,  Bk  >*  Yk. 

•  If  A  =prjl  Elim[J,A2](Ai){A"}  C,then  A>*0i,\Y :  A' .  (E\\m[I' ,  B']{B){B}  C')  B'  where 
A 1  =prjL  B,  and  A 2  =pv L  B',  and  I  =fjVi  I' ,  and  for  all  i,  A"  =3 VL  Bi  and  for  all  j, 
Cj  =(mv,  Cj  and  for  all  k,  B'k  >*Yk. 

Proof  The  proof  for  each  of  the  cases  is  similar  and  is  by  induction  over  the  length  of  the 
equivalence  relation.  We  will  show  only  one  case  here. 

•  Suppose  A  =jjr]L  X  A.  By  the  induction  hypothesis,  there  exists  an  A"  such  that 
A"  >*t,  A Y:A!.  [X  B  C)  and  A  A"  or  A"  >0L  A. 

-  The  case  where  A  \>pL  A"  is  immediate. 

-  The  case  where  A  [>v  A"  follows  from  the  lemma  of  delay  of  //-reduction. 

-  If  A"  [>jt  A,  then  the  required  result  follows  from  the  confluence  of  3d  reduction. 

-  Suppose  A"  \>v  A.  Then  from  the  confluence  of  reduction  on  u n marked  terms,  we 

get  that  ||  A  ||  \>*X  I)  where  j  B,  |  >/3Vl'0  B>i.  From  the  lemma  of  delay  of  //-reduction, 
we  get  that 

||  A  ||  \ Y:_.X  D'F>*X  D 
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From  proposition  C.  1. 16  we  can  deduce  the  existence  of  a  term  A±  such  that  A  \>%,  A\ 
and  ||  Ai  |j=  A Y :  X  D'F.  The  required  result  follows  from  here. 

□ 


C.1.2  Classification  of  terms 

Definition  C.1.18  We  partition  the  set  of  terms  into  four  classes:  the  set  of  types  Ty,  the  set  of 
kinds  Ki,  the  set  of  kind  schemas  Sc,  and  Ex.  The  class  of  a  term  is  defined  as  follows: 

Cls(Kind)  =  Sc 
Cls(Kscm)  =  Ex 
Cls(a)  =  Ty 
Cls(j)  =  Ki 
Cls(z)  =  Sc 
CIs^  A2)  =  Cls(yli) 

Cls(AA':A1.Al2)  =  Cls(Al2) 

Cls(ILA :  A\.  A2)  =  Cls(^42) 

Cls(lnd(X :  Kind){^4})  =  Ki 
Cls(Ctor  (i,  Ai))  =  Ty 

Cls(Elim[/,  A2](A1){A})  =  Ty  if  Cls(^42)  =  Ki,  else  Ki 
We  also  define  the  following  function: 


lift(Ty)  =  Ki 
lift(Ki)  =  Sc 
lift(Sc)  =  Ex 

Lemma  C.l. 19  If  A  F  A  ]  :  ,4 2  is  derivable,  then  we  have  lift(Cls(,4 1 ) )  =  Cls(,42).  In  particu¬ 
lar. ;  ,4 1  f  Ext.  Moreover,  for  all  pairs  (X.  A)  in  A,  we  have  Cls(,4)  =  liftfCls(A'j). 

Proof  Immediate  by  induction  over  the  derivation  of  the  judgment.  □ 

C.l. 3  Well  typed  terms 

We  now  consider  the  well  typed  terms.  The  following  lemmas  are  proved  easily  by  induction  over 
the  typing  derivations. 
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Lemma  C.1.20  (Substitution)  If  we  can  derive  A  i,  (X,  A),  A2  l-  B  :  C  and  A\  h  A2  :  A,  then 
we  can  derive  Ai,  ([A2/ X\/^f)  I-  \A2IX\B  :  \A2IX\C. 

Proof  Straightforward  induction  over  the  structure  of  the  derivation.  □ 

Lemma  C.1.21  If  we  can  derive  Ai,  ( X ,  A),  A2  h  B  :  C,  then  we  also  have  that  Ai  h  .4  :  .s 
for  some  sort  s.  Moreover,  we  also  have  that  Ai,  ( X ,  A),  A2  h  ^4  :  s. 

Proof  The  proof  is  by  induction  over  the  structure  of  the  derivation.  □ 

Lemma  C.1.22  If  we  have  that  A  b  BX  :A.B:s,  then  we  have  that  A,  X :  A  b  B  :  s. 

Proof  The  only  interesting  case  is  for  the  CONV  case  which  follows  from  Corollary  C.1.11.  □ 

Lemma  C. 1.23  If  the  judgment  A  \~  A  :  B  is  derivable,  then  either  B  =  Ext,  or  A  b  B  :  sfor 
some  sort  s. 

Proof  The  proof  is  a  straightforward  induction  over  the  structure  of  the  derivation.  □ 
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Lemma  C.1.24  (Inversion)  If  the  judgment  Ah  A  :  B  is  derivable,  then 


A  = 

a 

a  €  A, 

B  prjL  A(o:), 

Ah  B  :  Kind 

A  = 

j 

j  e  A, 

II 

to 

-3 

> 

Cl? 

Ah5:  Kscm 

A  = 

z 

zeA, 

to 

II 

to 

-3 

> 

A  h  B  :  Ext 

A  = 

Kind 

B  =pm  Kscm 

A  = 

Kscm 

B  =  Ext 

A  = 

UX:Ai.A2 

<1 

:  si,  A,  X  :A\ 

h  A2  :  s2,  B 

where  si  is  any  sort  and 

s2  =  Kind,  or,  s\  e  {Kind,  Kscm}  and  s2  =  Kscm 
A  =  AX:A!.A2  =>  A  h  A1  :  su  A,X:A1  h  A2  :  A3,  A  h  A3  :  s2 

B  =pnLILX:Ai.A3,  Ah  B  :  s2 

A  =  A!A2  =►  A  h  Ai  :  IIXiB'.A',  Ah  A2  :  B',  B  =pm  \A2/X\A’ 

A  =  lnd(A:  Kind){A}  =>  A,  A: Kind  h  At  :  Kind,  wfcx(Ai),  B  =pm  Kind 

A  =  Ctor(i,/)  =>  I  =  lnd(A :  Kind) { ^4} ,  same  conditions  on  I ,  B  [I/X]  Ai 

A  =  Elim[I,  A'](A){B}  =$■  I  =  lnd(A :  Kind) {^4} ,  same  conditions  on  I 

Ah  A:  I,  A  h  A' :  J  — »■  Kind,  AhB:  Kind 
B  =,3Vt,  AI  A,  Ah  Bi  :  C x,i(Ai ,  A',  Ctor  (*,  /)) 

A  =  Elim[I,  A'](A){B}  =>•  /  =  lnd(A :  Kind) {^4} ,  same  conditions  on  I 

Ah  A:  I,  A  h  A' :  Kscm 

A  h  B  :  Kscm  and  B  =pm  Ai 

A  h  Bi  :  x,i{Ai,  A'),  for  all  i  small  (Ai) 

Proof  By  induction  over  the  structure  of  the  derivation.  For  every  case  we  consider  the  set  of 
possible  typing  derivations.  □ 

Lemma  C.1.25  (Uniqueness  of  types)  If  A  h  A  :  A\  and  A  h  A  :  A2,  then  A\  =JgJ?t  A2. 
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Proof  By  induction  over  the  structure  of  A.  We  use  the  fact  that  if  Ai  =jgT?(.  B  and  A2  =3,v  B, 
then  A\  =pVi,  A-2-  For  every  case,  we  use  the  corresponding  clause  from  lemma  C.1.24.  □ 

Corollary  C.1.26  Suppose  A  is  a  well  typed  term.  If  A  O,/  A',  then  A  [>,,  A'. 

C.1.4  Reductions  on  well  typed  terms 

Lemma  C.1.27  (Subject  reduction  for  fh  reduction)  If  the  judgment  A  \~  A  :  B  is  derivable, 
and  if  A  \>gL  A'  and  A  \>/3l  A',  then  we  have  that 

A  h  A'  :  B  A'  F  A  :  B 


Proof  The  interesting  cases  are  the  APP  and  ELIM. 

•  APP  When  only  the  sub-terms  reduce  without  a  reduction  at  the  head,  the  lemma  follows  by 
using  the  induction  hypothesis  on  the  sub-terms.  Suppose  that 

A  F  A  :  nX:B'.  A!  A  F  B  :  B' 

A  =  XX:A1.A2  A  \-AB:[B/X}A' 

and  A  B  \>  a  [/i/A'],42.  We  know  from  lemma  C.1.24  that 

A,A:^i  F  A2  :A3 
UX:A1.A3  =;V  n X-.B'.A' 

A  F  A\  :  si 
A  F  B’  :  s 2 

This  implies  that  A\  =pVL  B’  and  A3  =pVi,  A1.  Moreover, 

CIS  {B')  =  Cls(Ai)  =  lift(Cls(A)) 


Therefore,  we  get  from  lemma  C.  1. 19  that 

Cls(s2)  =  Cls(si)  =4>  S 2  =  Si 

Applying  the  CONV  rule  we  get  that  A  F  B  :  A\.  By  lemma  C.1.20  we  get  that  A  F 
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[B/X\A2  :  \B/X]A^.  We  can  show  in  a  similar  manner  as  before  that  Cls(  Aj)  =  Cls(A). 

This  allows  us  to  apply  the  CONV  rule  again  which  leads  to  the  required  result. 

•  L-ELIM  We  will  only  consider  the  case  when  an  i  reduction  takes  place  at  the  head.  The 
other  cases  follow  easily  by  structural  induction. 

Ahi:I  A  I -A'  :  Kscm 

for  alii  A  \~  Bi  :  ^ x,i(Ci,A ') 

A  F  Elim [I,A’](A){B}  :  A' 
where  I  =  lnd( X :  Kind) {C}and  V*.  small(Ci) 

The  interesting  case  is  when  we  consider  the  reduction 

Elim[7,A](Ctor(i,7)  A){B}  >t  Bi))  A 

where  I  =  lnd(X :  Kind){C} 

B'  =  XY  :7.  (Elim[7,  A](y){7?}) 

Suppose  A"  =  Bi))  A.  Suppose  that  A  =  A\  ^n.  We  have  that  A  E  Bi  : 

T xj( Cf ,  A').  The  proof  is  by  induction  on  the  fact  that  C,  is  a  kind  of  a  constructor  and  the 
length  of  A.  We  consider  the  different  cases  by  which  Cf  is  a  kind  of  a  constructor. 

-  If  Ci  =  X ,  then  A"  =  Bi.  From  definition  5.4.6  we  can  see  that  in  this  case,  Bi  has 
the  type  A'. 

-If  Ci  =  ny  :B.C,  then 

A”  =  (QxjMiAi/Yj^Bi  A{))  A2...n.  We  have  that  A  F  Bt  A\  :  ^ Xj([Ai/Y)C,  A'). 
By  the  induction  hypothesis,  the  reduct  has  type  A'. 

-If  Ci  =  UY  :B.X^C,  then 

71"  =  &x,iMC,Bi  A1  (A Y:B.B'  (A1  f')))  A2...n 

From  Definition  5.4.6  we  have  that 

A  F  Bi  :  [I/X\A  -»•  [A'/X\A  ->  ^x,i{C,  A').  We  also  know  that  A  F  Ax  : 

[7/ X]  A.  From  here,  we  can  apply  the  induction  hypothesis  and  show  that  the  reduct 
has  type  A'. 
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•  ELIM  We  will  only  consider  the  case  when  an  i  reduction  takes  place  at  the  head.  The  other 
cases  follow  easily  by  structural  induction. 

Ah  A:  I  AhT  :  /  -»•  Kind 
for  alii  Ah  Bi  :  Cx,i{Ci,  A',  Ctor  (*,  /)) 

A  h  Elim[/,A/](A){S}  :  A!  A‘ 
where  I  =  lnd(A :  Kind){C} 

The  interesting  case  is  when  we  consider  the  reduction 

Elim[/,A'](Ctor(i,/)  A){B}  >t  ($A A 
where  I  =  lnd(A :  Kind){C} 

B '  =  XY:I.{E\\m[I,A']{Y){B}) 

Suppose  A"  =  Bi))  A.  Suppose  that  A  =  A\^n.  We  have  that  Ah  Bh  \ 

(x,i(Ci,  A',  Ctor  (i,  /)).  By  using  the  inversion  lemma  we  can  get  that  A  h  B'  :  IIA  : 
I.  A'  X.  By  induction  on  the  structure  of  Cr  (where  Ct  is  a  kind  of  a  constructor),  we  can 
show  that  if  Ct  =  UY  :  B.  A.  then  A  h  §x,i,B>{Ci,  Bt)  :  UY  :  B.  A!  Ctor  (i,  I)  Y.  The 
required  result  follows  from  here. 

□ 

Corollary  C.1.28  Suppose  A  is  a  well  formed  term.  If  A  \>  f.  A',  then  A  t>*^  A!  and  A'  is  well 
formed. 

Corollary  C.1.29  Suppose  A  is  a  well  formed  term.  If  A  [>  *  A',  then  there  exists  a  well  formed 
term  A"  such  that  A  D>^t  A"  [>*  A!. 

Lemma  C.1.30  Let  Ah  A  :  B  and  Ah  A'  :  B'  be  two  derivable  judgments.  If  A  =pni  -4,1  then 

Cls(A)  =  Cls(A'). 

Proof  We  know  that  ||  A  ||  and  |  A’  |  have  a  common  reduct,  say  A  2.  This  implies  that 
II A II  >%p0- B  A2  and  ||  A'  ||  >*  A2 
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From  here  we  get  that 


A  \>*pL  Bo  and  A'  >^4  B'q  where  || Bq  ||=  B  and  \\Bf\\=  B' 

Eta  reduction  does  not  change  the  class  of  a  term.  Moving  from  marked  to  unmarked  terms  also 
does  not  change  the  class  of  a  term.  Therefore,  we  get  that 

Cls(A)  =  Cls(-Bo)  =  Cls(.B)  =  CIs(A2)  and 
Cls(A2)  =  CIs  {B')  =  Cls(fT0)  =  Cls(A') 

□ 

Corollary  C.1.31  Let  A  F  A  :  si  and  A  F  B  :  s2  be  two  derivable  judgments.  If  A  =^r;,  B, 
then  si  =  s2. 

Lemma  C.1.32  If  Ai,  Y  :  C,  A2  F  A  :  B  and  Y  f  FV{ A2)  U  FV{A),  then  there  exists  a  B' 
such  that  AiA2  F  A  :  B' .  ( This  also  implies  that  B  =[jr]L  B'). 

Proof  The  proof  is  by  induction  on  the  structure  of  the  derivation.  We  will  consider  only  the 
important  cases. 

•  case  FUN.  We  know  that 

Al,Y:C,A2,X:A  F  B  :  B'  Ai,F  :(7,  A2  F  UX :  A.  B'  :  s 
A1,Y:C,A2  F  XX-.A.B  :  UX:A.B' 

Applying  the  induction  hypothesis  to  the  formation  of  B 

Ai A2, X-.AL  B-.C'  B'  =0Vi  C' 


By  lemma  C.1.23  we  have  that 

AiA 2,X:A  F  C'  :  s  which  implies  AiA2  F  n A:  AC"  :  s 
Therefore  we  get  that 

Ai  A2  F  XX-.A.B  :UX:  A.  C' 
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•  case  APP  We  know  that 


A1,Y:C,A2  b  A:  UX.B'.A'  AUY:C,A2  b  B  :  B' 
A1,Y:C,A2  b  AB:  jj B/X]A 7 

By  applying  the  induction  hypothesis  we  get  that 


AxA2  b  A:  A2  and  AiA2  b  B  :  A3  where  A2  =pr]L  UX:B'.  A'  and  A3  =pVi  B' 


From  lemma  C.  1. 17,  A2  l>;3t  A Y :  A.  (IX  X :  B" .  A")  B.  Since  (3t  reduction  preserves  type, 
and  A2  is  well  formed,  we  have  that  ,4  2  IT  A'' :  B" .  A" .  This  implies  that  A"  — 0riL  ^4 
and  B"  =pVi.  B'.  We  also  get  that  A3  =3ni  B".  From  corollary  C.1.31  we  get  that  A3  and 
B"  have  the  same  sort.  By  applying  the  CONV  rule  we  get  that 

Ai  A2  b  A:UX:  B" .  A"  and  AXA2  b  B  :  B" 

Therefore,  we  get  that 

AiA2  b  AB:  \ B/X\A " 


□ 

As  a  corollary  we  now  get  that 

Lemma  C.1.33  (Strengthening)  IfA1,Y:C,A2  b  A  :  BandY  £  FV{A2)UFV{A)UFV{B), 
then  AiA2  b  A  :  B. 

Lemma  C.1.34  (Subject  reduction  for  ? 7  reduction)  If  A  b  A  :  B,  and  A  [>r]  A'  and  A  \>  q  A', 

then  we  have  that 

A  b  A'  :  B  A'  b  A  :  B 

Proof  The  interesting  case  is  that  of  functions.  Suppose  that 

A  b  XX:A1.A2  X  :  B  X  f  FV{A2)  A X:AVA2  X  >VA2 
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From  lemma  C.  1.24  we  know  that 


A,X:Ai  h  A2  X  :  A3  B  =pr/l  UX :  Ax .  A3  Ah  B:s 

Again  applying  lemma  C.1.24  we  get  that 

A,  X:A,  h  A2  :  n Y:B'.A!  B'  Ai  A3  =em.  [- X/Y ]A! 

By  applying  the  CONV  rule  now,  we  get  that  A,  X :  A\  h  A2  :  B.  By  applying  lemma  C.  1.33  we 
get  that  A  h  A2  :  B.  □ 

Theorem  C.1.35  (Subject  reduction)  If  A  h  A  :  B,  and  A\>  A'  and  A  >  A',  then  we  have  that: 
A  h  A'  :  B  and  A'  h  A:  B. 

Proof  Follows  from  lemma  C. 1.27  and  C. 1.34.  □ 


C.2  Strong  normalization 

The  proof  is  structured  as  follows: 

•  We  introduce  a  calculus  of  pure  terms.  This  is  just  the  pure  A  calculus  extended  with  a 
recursive  filtering  operator.  We  do  this  so  that  we  can  operate  in  a  confluent  calculus. 

•  We  define  a  notion  of  reducibility  candidates.  Every  schema  gives  rise  to  a  reducibility 
candidate.  We  also  show  how  these  candidates  can  be  constructed  inductively. 

•  We  then  define  a  notion  of  well  constructed  kinds  which  is  a  weak  form  of  typing. 

•  We  associate  an  interpretation  to  each  well  formed  kind.  We  show  that  under  adequate 
conditions,  this  interpretation  is  a  candidate. 

•  We  show  that  type  level  constructs  such  as  abstractions  and  constructors  belong  to  the  can¬ 
didate  associated  with  their  kind. 

•  We  show  that  the  interpretation  of  a  kind  remains  the  same  under  (3rj  reduction. 

•  We  define  a  notion  of  kinds  that  arc  invariant  on  their  domain  -  these  arc  kinds  whose  inter¬ 
pretation  remains  the  same  upon  reduction. 
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•  We  show  that  kinds  formed  with  large  elimination  arc  invariant  on  their  domain. 

•  From  here  we  can  show  the  strong  normalization  of  the  calculus  of  pure  terms.  We  show  that 
if  a  type  is  well  formed,  then  the  pure  term  derived  from  it  is  strongly  normalizing. 

•  We  then  reduce  the  strong  normalization  of  all  well  formed  terms  to  the  strong  normalization 
of  pure  terms. 

C.2.1  Notation 

The  syntax  for  the  language  is: 


( ctxt ) 

A  : 

::=  •  |  A,X:A 

(sort) 

s  : 

::=  Kind  |  Kscm  Ext 

( var ) 

X  : 

Q 

II 

(ptm) 

A,  B  : 

::=  s  |  A  |  XX:A.B  \  A  B  \  UX-.A.B  \  lnd(X :  Kind){A} 

Ctor(i,A)  |  Elim[A', B'\(A){B} 

The  proof  of  strong  normalization  uses  the  stratification  in  the  language  shown  below. 


(ctxt) 

A  : 

:=  •  A  ,z:  Kscm  |  A,  j :  u  \  A,  a :  k 

(kscm) 

u  : 

:=  z  |  IIq: :k.u  \Hj  :ui.U2  \  Kind 

(kind) 

k  : 

:=  j  Xa:K\.  K2  h[t\  \  Xj  :u.  k\  k\  K2  fla :  K\ .  rt2  ILj  :u.  k 

IIz:Kscm.K  lnd(j : Kind){i?}  |  Elim[«;',tt](r){K} 

(type) 

t  : 

:=  a  \  Xa:  k.  t  \  ti  T2  \  Xj :  u.  t  \  r[«]  Az:  Kscm.  r  |  t[u\ 

Ctor(z,  k)  Elimfre',  k](t,){t} 

In  this  section,  the  types  arc  also  referred  to  as  proof  terms.  We  sometimes  use  I  to  refer  to  an 
inductive  definition. 

C.2.2  Pure  terms 

The  pure  terms  arc  defined  as: 

(A)  a,  b,  c  ::=  a  |  a  b  |  X a.a  \  Co(n )  j  match  a.{a} 
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The  set  of  reductions  on  the  pure  terms  arc  defined  as: 


(A a.a)  b  \>p  [b/a]a 

X a.(a  a)  a  if  a  FV (a) 

match  a. {a}  (Co (i)  b)  t>L  ([match  a.{a}/a]a;)  b 

The  translation  from  types  to  pure  terms  is  defined  as: 

|  a  |  =  a 

In  r2  |  =  |ri  |  |  r2  | 

I  T[K\  |  =  |  T  | 

I  T[U\  |  =  |  T  | 

|  Xa:  n.  t  |  =  Aa.|  r  | 

\Xj  :u.t\  =  \t\ 

|  A2::  Kscm.r  |  =  |  r  | 

|  Ctor  (n,  k)  I  =  Co (n) 

- » 

|  Elim[«,  k/](t){t}  I  =  (match  a.{  Y(/«i,  \t,\,  X a2.cr  a2)})  |  r 
where  k  =  lnd(j :  Kind){i7}  and 


Y O',  ci\,  a2)  —  ai 

T(ncr:  ki.  k2,  ai,  a2)  =  Aa.Y(ft2,  ai  cr,  a2) 

T (IT/ :  u.  re,ai,a2)  =  Y(k,  ai,a2) 

Y(IIz :  Kscm.  k, ai,  a2)  =  Y(«,  ai,  a2) 

Y(ILY  :A.j  — r  re,  ai,  a2)  =  Aa.Y(re,  ai  a  (A|  X  |.a2  (a  |  X  |)),  a2) 

Lemma  C.2.1  Let  r  and  t'  be  two  well  formed  types  and  let  a  be  a  type  variable.  Then  |  [r'/ajr  |  = 
[|r'|  /a]  |r|. 

Proof  It  is  a  straightforward  proof  by  induction  over  the  structure  of  r.  □ 

The  following  lemma  uses  Definitions  5.4.6  and  5.4.4  in  Section  C.l  and  also  the  definition  of 
T  from  above. 

- * 

Lemma  C.2.2  |  &x,i,b{k,  t)  |=  [match  a.{T (re*,  \  Ti  |,  Aa2.a  cr2)}/a]Y(re,  |  r  |,  Aa2.a  a2) 

Proof  The  proof  is  by  induction  on  the  fact  that  re  is  the  kind  of  a  constructor.  □ 
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Lemma  C.2.3  For  all  well  fanned  proof  terms  T\  and  T2,  if  t i  72,  then  |  n  |  \>3  \  T2  \  where 

j  <  i- 

Proof  Follows  from  lemmas  C.2.1  and  C.2.2.  □ 

C.2.3  Interpretation  of  schemas 

Definition  C.2.4  (Arity)  We  call  ground  kind  schemas  arities  denoted  as  arity (  u.  Kind).  The  ari- 
ties  are  defined  with  the  following  grammar: 

(. kscm )  u  ::=  Kind  |  Tij  \U\.U2  |  II a:n.  u 

Definition  C.2.5  (Schema  map)  We  define  a  kind  schema  mapping  K,  as  a  function  mapping  kind 
schema  variables  z  to  arities.  We  also  use  1C,  z  :  u  to  say  that  K,  has  been  augmented  with  the 
mapping  z  h- >  u. 

Definition  C.2.6  We  define  the  function  p(u)jc  as: 

p{u)k  =  po(JC(u))  where 

•  po(Kind)  is  the  set  of  sets  of  pure  terms; 

•  Po{Uj :  u\.  uf)  is  the  set  of  functions  from  pq{u{)  to  po{u2)t  and 

•  /)o(IIa :  k.  u )  is  the  set  of  functions  from  A  to  po(u). 

Definition  C.2.7  For  each  kind  schema  u  and  mapping  1C,  we  define  in  p(u)fc  the  relation  of 
partial  equivalence  written  as  as  follows: 

•  for  all  C  and  C'  in  po(Kind),  we  have  that  C  — «jnc|  C'  C  =  C"; 

•  for  all  C  and  C  in  po(IIi  :  «i-  uf),  we  have  C  —njui.v.2  C  <^==^>  for  and  C‘>  in 

Po{ui)  with  C\  —Ul  C2  we  get  that  C  C\  ~U2  C'  C2;  and 

•  for  all  C  and  C'  in  p^ijia :  k.  u ),  we  have  that  C  ^nojc.  u  C'  for  all  a  and  b  in  A  such 
that  a  =pVL  h  we  get  that  C  a  czu  C'b. 

Definition  C.2.8  (Invariant)  Given  C  in  p(u)  ic,  we  say  that  C  is  invariant  C  ~^(u)  C. 
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Definition  C.2.9  (Neutral  terms)  A  term  is  called  neutral  if  it  has  neither  of  the  following  forms 
-  A a.a,  Co (*)  a,  or  match  a.{a}. 

Definition  C.2.10  We  define  C72o(Kind)  as  consisting  of  all  sets  C  such  that: 

•  if  a  C  C,  then  a  is  strongly  normalizing; 

•  ifa\>  U2  and  (i\  G  C,  then  02  G  C;  and 

•  if  a  is  neutral  and  for  all  terms  a'  such  that  a  >  a'  and  a'  G  C,  then  a  G  C. 

Definition  C.2.11  (Candidates)  We  define  C1Z(u)jc  as  a  subset  of  p{u)x.  as: 

CTZ{'u)rc  =  CTZq(IC(u))  where 

•  C7^-o (Kind)  is  defined  as  in  Definition  C.2.10; 

•  ClZolTla  :  n.u)  is  the  set  of  invariant  elements  C  belonging  to  poifla  :  k.u)  such  that 
C  Ac  ClZ(fiu);  and 

•  ClZolTlj  :  ii\.  uf)  is  the  set  of  invariant  elements  C  belonging  to  poijlj  \U1.U2)  such  that 
C  (C1Zq(u\))  C  C1Zo(u2). 

Proposition  C.2.12  All  reducibility  candidates  are  invariant. 

Proposition  C.2.13  Let  ( Ci)ieI  be  a  family  of  reducibility  candidates  o/Kind  indexed  by  a  set  I. 
Then  n,e/-C't  is  a  reducibility  candidate  of  schema  Kind. 

Lemma  C.2.14  Let  C  G  p{u)  IfC  is  invariant,  then 

C  G  ClZ(u)K  <=►  VC'  G  Dom(CK(u)K).C  C  G  C1Z{ Kind)^ 

Proof  Straightforward  induction  over  the  structure  of  KL(  u).  □ 

Definition  C.2.15  Let  a\  be  a  strongly  normalizing  term.  Then  the  length  of  the  longest  sequence 
of  reductions  to  a  normal  form  is  denoted  as  v{a  1). 
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Lemma  C.2.16  Let  a\  and  a 2  be  two  terms  and  let  C  £  C75,o  ( Kind)  be  a  reducibility  candidate. 
If  02  is  strongly  normalizing,  and  if[a2/a]a\  £  C,  then  (Aa.ai)  02  £  C. 

Proof  By  induction  over  v(a\)  +  1/(02).  □ 

Corollary  C.2.17  Let  01  be  a  pure  term  and  let  C  be  a  reducibility  candidate  of  schema  Kind.  Let 
a  and  a'  be  respectively  a  sequence  of  variables  and  terms  of  the  same  length.  If  for  all  i,  a\  is 
strongly  normalizing,  and  if[a'/a]ai  £  C,  then  (Aa.ai)  o!  £  C. 

Lemma  C.2.18  For  all  reducibility  candidates  C  of  kind  Kind,  for  all  sequences  of  strongly  nor¬ 
malizing  a  and  h  and  for  all  i  less  than  the  length  of  a,  we  have  that 

match  a. {a}  (Co(i)  b)  £  C  ([match  a.{a}/a]aj)  b  £  C 

Proof  Follows  by  induction  over  v(a.j)  +  lAbi)  (for  all  i).  □ 

Definition  C.2.19  (Canonical  candidates)  Define  Can(u)^;  as: 

Can  (u)ic  =  Cano  (JC(u))  where 

•  Cano  (Kind)  is  the  set  of  all  strongly  normalizing  terms; 

•  Can(|(rTa: :  k.  u )  is  the  function  mapping  all  pure  terms  to  Cano(a);  and 

•  Can  0  (IF/ :  ui.  uf)  is  the  function  mapping  all  elements  of  po{uf)  to  Cano(n2). 

C.2.4  Properties  of  candidates 

In  this  section,  we  state  some  properties  of  the  reducibility  candidates.  The  properties  with  respect 
to  the  union  and  the  intersection  of  a  family  of  candidates  will  be  used  for  the  inductive  construc¬ 
tions  of  candidates. 

Definition  C.2.20  (Order  over  candidates)  For  each  kind  schema  u  and  mapping  1C,  we  define  in 
p(u)fc  the  relation  <jc(u)  as  follows: 

•  for  all  C  and  C'  in  po(Kind),  we  have  that  C  <Kjnc|  C'  C  C  C ; 
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•  for  all  C  and  C'  in  po(nj  :  u\.  u2),  we  have  C  <ujm.u2  C'  for  all  C\  in  po(ui),  we 
get  that  C  C\  <U2  C  C\ ;  and 

•  for  all  C  and  C'  in  p$(Jla  :  n.  u ),  we  have  that  C  <n an.u  C'  for  all  a  in  A,  we  get 

that  C  a  <u  C'  a. 

Definition  C.2.21  For  all  schemas  u  and  mapping  1C,  for  all  families  of  elements  in  p(u)/c,  we 
define  f\ieI  Ci  as: 

•  for  all  Ci  e  /90(Kind),  /\iej  Ci  =  n ieiCa 

•  for  all  Ci  £  /?o(na :  k.  u),  /\ieI  C,  =  ft  £  A  h>  Aie/  Ci  b;  and 

•  for  all  Ci  €  po(Hj : ui.u2),  Aie/  Ci  =  C1  €.  po(ui)  Aie/  Ci  C". 

Lemma  C.2.22  Let  u  be  a  schema  and  1C  a  mapping  and  Ci  a  family  of  elements  of  p(u)fc.  Then 

Vj  G  I,  Aie/  Ci  <jc(«)  Cj. 

Proof  It  follows  in  a  straightforward  way  by  induction  over  the  structure  of  tC(u).  □ 

The  following  two  propositions  also  follow  easily  by  induction  over  the  structure  of  K.(u). 

Proposition  C.2.23  Let  u  be  a  schema  and  1C  a  mapping  and  Ci  a  family  of  elements  of  p(u)fc.  If 
all  Ci  are  invariants,  then  the  same  holds  for  Aie/  Ci- 

Proposition  C.2.24  Let  u  be  a  schema  and  1C  a  mapping  and  Ci  a  family  of  elements  of  C'lZ(u') 
Then  we  also  have  that  Aie/  Ci  £  CTZ(u)jc. 

Corollary  C.2.25  We  get  that  (ClZ(u)fc,  <jc(u))  ’s  an  inf-semi-lattice  for  all  schema  u  and  map¬ 
ping  1C.  We  use  min(lC(u ))  to  denote  the  smallest  element. 

Definition  C.2.26  For  all  schemas  u  and  mapping  1C,  for  all  families  of  elements  in  p(u)  x:,  H’<? 
define  \fieI  Ci  as: 

•  for  all  Ci  G  po(Kind),  Vie/  Ci  =  Ui6/Ci/ 

•  for  all  Ci  G  po(na :  k.  u),  \fieI  Ci  =  b  £  Ae>  Vie/  Ci  b;  and 

•  for  all  Ci  G  poiflj :  ui.u2),  Vie/  Ci  =  C'  G  po(ui)  \Ji£l  Ci  C’ . 
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Lemma  C.2.27  Let  ube  a  schema  and  1C  be  a  mapping.  Let  and  ( C'i)i£l  be  two  families 

of  elements  of  p(u)jc.  If  for  all  elements  i  of  I  we  have  that  Ci  —k.{u)  C'i>  then  we  a^so  have  that 
Vie/  Ci  — K{u )  Vie/  C[- 

Proof  Straightforward  induction  over  the  structure  of  K(u).  □ 

Corollary  C.2.28  Let  ube  a  schema  and  1C  be  a  mapping.  Let  ( Cf)ieI  be  a  family  of  elements  of 
p(u)fc-  If  all  Ci  are  invariant,  then  Vie/  Ci  is  also  invariant. 

Lemma  C.2.29  Let  u  be  a  schema  and  1C  be  a  mapping.  Let  (Cf)i£l  be  a  family  of  elements  of 
p{u)ic  and  C  G  p(u)jc.  If  for  all  i,  Ci  <k,{u)  C,  then  Vie/  Ci  <K(U)  C. 

Proof  The  proof  is  by  induction  over  the  structure  of  K{u).  □ 

Lemma  C.2.30  Let  ( Cf)ieI  be  a  totally  ordered  family  of  elements  of  CTZ(u)jc.  Then  Vie/  Ci  G 
C1Z(u)jc. 

Proof  The  proof  is  by  induction  over  the  structure  of  K{u).  Suppose  Vie/  Ci  =  C' . 

•  K,{u)  =  Kind.  We  have  to  make  sure  that  all  three  conditions  in  Definition  C.2.10  are 
satisfied.  The  first  two  conditions  follow  obviously.  For  the  third  case,  assume  that  a  is 
neutral  and  for  all  terms  a,  such  that  a  [>  a,,,  we  have  that  a,  <£  C .  This  implies  that  ai  F  Cj 
for  some  j.  Since  there  are  finitely  many  such  Cj  and  they  are  totally  ordered,  we  can  choose 
a  Cj.  among  them  that  contains  all  the  Cj s.  Since  this  C\  is  also  a  candidate,  it  contains  a. 
Therefore,  a  G  Vie/  Ci- 

•  K,{u)  =  IIq;  :  k.  u.  Since  all  the  Ci  are  invariant,  it  follows  from  Definitions  C.2.7  and  C.2.8 
that  for  a  term  a  G  A,  we  have  that  Ci  a  is  invariant.  Again  from  Definition  C.2.20,  it  is 
clear  that  the  Ci  a  are  totally  ordered.  Also  from  Corollary  C.2.28  we  get  that  \JieI  Ci  a 
is  invariant.  Applying  the  induction  hypothesis  we  get  that  Vie/  Ci  a  G  ClZf  u).  From 
Definition  C.2.11,  it  follows  that  Vie/  Ci  €  C7^o(na  :n.u). 

•  K{u)  =  ITj :  ui .  11.2 .  Similar  to  the  previous  case. 

□ 
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Definition  C.2.31  (Schema  interpretation)  A  schema  interpretation  Id  is  a  function  that  maps  a 
kind  variable  j  to  an  element  of  p(u)jc.  We  also  use  ld,j:C  to  say  that  U  has  been  augmented  with 
the  mapping  j  i— >  C. 


Definition  C.2.32  (Well  formed  kinds)  Let  u  be  a  schema,  k  be  a  kind,  1C  be  a  mapping,  and  U 
be  an  interpretation.  We  say  that  k  is  a  well  formed  kind  of  schema  K,(u)  under  1C  and  U  iff  : 

1.  k  =  j  and  U(j)  =  p(u)ic; 

2.  k  =  II  a  :  K\.  K2  with  JC(u)  =pVi  Kind  and  K\  and  K2  are  both  well  constructed  of  schema 
Kind  under  1C  and  U; 

3.  k  =  n j  :u' .  k'  with  lC(u)  =pr\L  Kind  and  k!  is  well  constructed  of  schema  Kind  under  K,  and 
U,y.p(:u!)ic 

4.  k  =  Hz  :  Kscm.  k'  with  JC(u)  =pnt  Kind  and  for  all  u'  such  that  v!  €  arity(tti,  Kind),  we 
have  that  rf  is  well  constructed  of  schema  Kind  under  fC,z:u'  and  U; 

5.  k  =  Ki  k  2  if  there  exists  two  schemas  u±  and  U2  with  K2  well  constructed  of  schema  fC(u2) 
under  1C  and  U,  also  K\  well  constructed  of  schema  KfTij  :  U2-U\)  under  1C  and  U,  and 

p(u)k  =  p([K2/j]ui))c; 

6.  k  =  K\  T\  if  there  exists  a  schema  U2  and  kind  k,2  such  that  K\  is  well  constructed  of  schema 
/C(IIa:  ti2-  uf)  under  1C  and U  and  p(u)jc  =  p([Ti/a]u2)tc>' 

7.  k  =  A  j  :u\.k  i  if  there  exists  a  U2  such  that  K\  is  well  constructed  of  schema  /C(«2)  under 
ICandU,j:p(ui)icandp(u)ic  =  p(Hj:ui.  u2)k; 

8.  k  =  \a :  K±.  K2  if  there  exists  a  U2  such  that  K2  is  well  constructed  of  schema  1C(u2)  under 
1C  and U  and  p(u)jc  =  p(Jia:n\.  U2)ici 

9.  k  =  lnd(j  :  Kind)  {/«}  if  all  Ki  are  kinds  of  constructors  and  well  constructed  of  schema  Kind 
under  K,  and  Id ,  j  :  po(K'\r\6),  and  p(u)jc  =  po(Kind);  and 

10.  k  =  Elimf/c',  u'](t){k}  if  k!  =  lnd(j  :  Kind)  and  k!  is  well  constructed  of  schema  Kind 
under  1C  and  U.  also  v!  is  a  schema  and  IC(u)  =f}r\i  an<3  Ki  is  well  constructed  of  schema 
/C(^j  k/(kJ,  u'))  under  1C  and  U. 
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Definition  C.2.33  We  define  compatible  mappings  and  interpretation  as: 


1.  A  mapping  K.  is  compatible  with  a  context  A  if  for  all  z  G  A,  we  have  fC(z)  =  arity(«,  Kind). 

2.  An  interpretation  U  is  compatible  with  a  context  A  and  a  compatible  mapping  K,  if  for  all 
pairs  ( j,u )  G  A,  we  have  U (j)  G  p(u)jc. 

Lemma  C.2.34  If  A  b  k  :  u,  then  for  all  compatible  K.  and  U,  we  have  that  k  is  well  constructed 
of  schema  JC(u). 

Proof  By  induction  over  the  structure  of  k.  □ 

C.2.5  Inductive  constructions 

Consider  an  increasing  function  F  in  p0(Kind)  for  the  order  <Kjnc|-  Denote  the  smallest  element 
of  /90(Kind)  as  A.  Since  po(Kind)  is  closed  under  n,  and  (po(Kind),  < Kind )  an  inf‘semi‘lattice' 
the  function  F  has  a  least  fixed  point  ( Ifp ).  We  will  construct  this  least  fixed  point  inductively.  We 
first  define  the  transfinite  iteration  of  F. 

Definition  C.2.35  Let  C  G  po(Kind)  and  o  be  an  ordinal,  lib  define  the  iteration  of  order  o  of  / 
over  C  as: 

•  F°(C)  =  C; 

•  F°+liC)  =  F(F°(C));  and 

•  FlimW  =  u  oeUF°(C). 

Lemma  C.2.36  Let  o  be  an  ordinal;  we  have  F°(F)  <p(jnc|  lfp(F). 

Proof  The  proof  is  by  induction  over  o.  If  o  =  0,  then  it  follows  immediately.  Otherwise, 

•  o  =  o'  +  1  Then  we  have  that  _F°(_L)  =  F(F°' (_L)).  By  the  induction  hypothesis,  we  get 
that  F(F°' (A.))  <Kjnd  F(lfp(F)).  This  implies  that  F(F°'(±_))  <Kjnd  lfp(F). 

•  o  =  lim(U )  Follows  immediately  from  the  induction  hypothesis  and  lemma  C.2.29. 

□ 
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Remark  C.2.37  Since  we  do  not  consider  the  degenerate  case  of  F(±)  =  _L,  it  follows  from 
lemma  C.2.36  that  for  some  ordinal  o,  we  have  that  lfp(F )  =  i?°(_L). 

Lemma  C.2.38  Suppose  S  is  a  subset  o//Jo(Kind)  satisfying: 

•  if(Ci)ieI  is  a  totally  ordered  family  of  elements  ofS,  then  U  ig/Cj  G  S; 

•  F(_ L)  G  S;  and 

•  for  all  C  in  S,  F(C )  G  S. 

Then  lfp(F)  G  S. 

Proof  Follows  from  the  fact  that  lfp(F)  =  F°(_ L)  for  some  ordinal  o.  □ 

Definition  C.2.39  Let  a  G  lfp(F).  We  define  deg  (a)  as  the  smallest  ordinal  such  that  a  G 
i?deg(a)(_g_ 

Definition  C.2.40  To  all  a  G  lfp(F),  we  associate  pred(a)  defined  as  Fc^e9(^a)~1(_L). 

Lemma  C.2.41  For  all  a,  deg  (a)  is  an  ordinal  successor. 

Proof  Suppose  it  is  the  limit  of  the  set  U.  From  Definition  C.2.35,  there  exists  some  o  G  U  for 
which  a  G  F°(_L).  This  leads  to  a  contradiction.  □ 

Definition  C.2.42  (Partial  order)  Suppose  C  and  C'  are  two  elements  o/C72o(Kind).  We  say  that 
C  <FC'  if  C  =  F°(±)  and  C'  =  F°'  (±),  and  o  <  o’. 

C.2.6  Interpretation  of  kinds 

In  this  section  we  interpret  kinds  as  members  of  reducibility  candidates.  First  we  augment  the 
schema  interpretation 

Definition  C.2.43  We  augment  U  so  that  it  maps  a  kind  variable  to  an  element  of  p{v)ic,  and  a 
type  variable  to  a  pure  term  a. 

Definition  C.2.44  We  denote  the  interpretation  of  a  type  r  as  Cfyir).  To  form  this,  we  first  con¬ 
struct  the  corresponding  pure  term  \  r  |  and  then  substitute  the  type  variables  by  the  corresponding 
pure  terms  in  U.  This  is  equivalent  to  U (\t\). 
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Definition  C.2.45  (Interpreting  kinds)  Consider  a  kind  k,  a  schema  u,  a  mapping  1C,  and  an 
interpretation  U.  Suppose  k  is  well  constructed  of  schema  lC(u )  under  K,  and  U.  We  define  by 
recursion  on  k: 

1.  C%{j)=U{j) 

2.  C^(Ua:K1.K2)  =  {a  G  A,Vai  G  Cft(ni),a  a\  G  C^a:oi(K2)} 

*  :«!•  Ki)  — 

4  c^(n2:Kscm.Kl)  =  nuigarity(.[tKind)c^:ul(«i) 

5.  C%{k i  r)  =  C£(/ci)  Cjj(r) 

6.  Cfi(Ki  k2)  =  i)  C^(k2) 

7.  ^(Aa:Ki.K2)  =  aGAi — >  cu,a:a(K  2) 

&  Cjj(Xj  \u\.K\)  =  C  G  Cfc(ui)/c  1 — »  Cu,j-.c(K  1) 

9.  C^(lnd(j :  Kind){  /?})  =  l/ie  least  fixed  point  of  the  function  F  from  po(Kind)  to  po(Kind) 
defined  as : 

for  all  S  G  po (Kind), /or  o/Z  C'  in  C1Z(I  — >  Kind)*;  ( where  I  =  I nd(j  :  Kind ){if}),  for  all 
sequences  of  pure  terms  bi,  with  for  all  i, 


bi  G  CU,j:S,A':C',B':CO(i)^j’I(Ki,A',B'^ 


F(S)  is  the  union  ofmin(  Kind)  with  the  set  of  pure  terms  a  such  that 

- > 

(match  a.{Cj%  b  (T(Ki,di,  Xa2.aa2))})  acC'  a 


10.  Cft(E\\m[K,u](T){K'})  =  G{Cfi{n)) 

where  k  =  lnd(j  :  Kind)!/?}  is  well  constructed  of  schema  Kind  under  K,  and  U  and  G(C )  G 
p(u)jc  is  defined  for  all  C  G  dom(<K )  as  follows  (<K  is  the  order  induced  by  the  inductive 
definition  n): 


•  IfCjj(r)  has  a  normal  form  b  =  Co(i)  a  such  that  b  G  C 


G'(C)  -  cJiai:G(pred (°) 
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Can(«)x:  otherwise 


Lemma  C.2.46  The  function  F  in  Definition  C.2.45.9  is  monotonic. 
Proof  We  must  prove  that  if  C\  <p(jnc|  C2,  then 


Cic 

U,j:C2,A'-C',B':C0(i) 


B '))  <Kjnd  Cu  j:CuA':C>,B>-.C ^  B'^ 


The  proof  is  by  induction  on  the  fact  that  Hi  is  the  kind  of  a  constructor. 

•  If  Hi  =  j,  then  both  sides  reduce  to  C'  Co  (i). 

•  If  Kj  =  HX  :  .4  ] .  .49.  then  it  follows  directly  from  the  induction  hypothesis  and  because  j 
does  not  occur  in  A\. 

•  If  Hi  =  II X :  A.  j  —>  Ar2,  then 

^{h^A'.B')  =  nZ:(nX:A.j).nX’:A.(A'  (Z  X'))  ^  CjAA2,  A',  B’  Z) 

Suppose  U'  =  U,j  :  C" ,  A!  :  C',  B'  :  Co(i)  where  C"  is  either  C\  or  62.  The  required  set 
is  then 

a  G  A,  such  that  Vai  G  Off, (TLX :  A.  j), 
Va2€C5,tZ:ai(UX':A.A'  (Z  X>)) 
a  ai  a2  ^  A  ,B  Z)) 

The  set  of  ai  and  a->  is  larger  for  the  LHS.  By  the  induction  hypothesis,  the  result  a  a  1  a 9 
must  occur  in  a  smaller  set  for  the  LHS.  The  required  result  follows  from  this. 

□ 


Remark  C.2.47  The  previous  lemma  ensures  that  the  interpretation  of  an  inductive  type  sets  up  a 
well  defined  order.  This  ensures  that  the  interpretation  of  large  elimination  (Definition  C.  2. 45. 10) 
is  well  formed. 

We  get  a  bunch  of  substitution  lemmas.  The  proof  for  each  of  these  is  similar  and  follows 
directly  by  induction  over  the  structure  of  n.  We  state  them  below: 
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Proposition  C.2.48  Let  n  be  a  well  constructed  kind  of  schema  u  under  K,  and  U.  Let  a  be  a  type 
variable,  and  r  a  type.  We  have  that 


Cu{[t/o\k)  =  C^a:CK{T){K) 

Proposition  C.2.49  Let  n  be  a  well  constructed  kind  of  schema  u  under  K,  and  U.  Let  j  be  a  kind 
variable  and  K\  a  kind  such  that  is  well  constructed  under  K,  and  U  of  the  same  schema  asU(j). 
We  have  that 

Proposition  C.2.50  Let  k  be  a  well  constructed  kind  of  schema  u  under  K,  and  U.  Let  z  be  a 
schema  variable,  and  u\  be  a  schema  such  that  K,{u\ )  is  an  arity.  We  have  that 

<S([«  i/*w  =  cLzMn\^) 

C.2.7  Candidate  interpretation  of  kinds 

Definition  C.2.51  We  say  that  U  and  U'  are  equivalent  interpretations  if  for  all  j,  we  have  that 
U(j)  —  U'(j )  and  for  all  a  we  have  that  U  (a )  =pr n  Ufa). 

Lemma  C.2.52  Let  u  be  a  schema,  1C  be  a  mapping,  and  U  and  U '  be  two  equivalent  inter¬ 
pretations.  Suppose  k  is  well  constructed  of  schema  K,(u )  under  K,  and  both  U  and  U' .  Then 
<#(«)  —k,(u)  C&{k). 

Proof  The  proof  is  by  induction  over  the  structure  of  n.  Most  of  the  cases  follow  directly  from 
the  induction  hypothesis. 

•  k  =  Elimf/v',  u](t){k,'}.  Here  k'  =  lnd(j  :  Kind){K}.  First  note  that  C^(k')  =  Cyf  f  ). 
Therefore,  the  function  F  whose  Ifp  generates  the  inductive  definition  is  the  same.  More¬ 
over,  Cu(t)  =finL  C jj,(T ).  Since  the  set  of  pure  terms  is  confluent,  C^(t)  and  C^,(t)  have 
the  same  normal  form.  We  can  now  do  induction  on  the  structure  of  n,  to  prove  that 


CK 

w,cn:G(pred(6)) 


□ 
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Lemma  C.2.53  Let  1C  be  a  mapping,  U  a  candidate  interpretation,  nbe  a  kind  and  u  be  a  schema 
such  that  k  is  a  well  constructed  kind  of  schema  K(u).  Then  g  cn{u)  K- 

Proof  The  proof  is  by  induction  over  the  structure  of  k.  Most  of  the  cases  follow  in  a  direct  way. 

•  k  =  lnd(j  :  Kind){/T}.  We  will  use  lemma  C.2.38  to  prove  this.  For  S  E  C72o(Kind),  the 
first  condition  is  satisfied  by  lemma  C.2.30. 

-  Suppose  S  =  _L.  If  none  of  the  branches  is  recursive  then  the  function  F  is  a  constant 
function  and  the  proof  is  similar  to  the  non-bottom  case.  Suppose  the  ith  branch  is 
recursive.  Then  it  is  easy  to  see  that  the  bt  defined  as: 


(z  pic 

1  ^  UU,j:X,A':C,B':CO(i) 


includes  the  set  of  all  terms,  including  non-normalizing  ones.  Therefore,  there  are  no 
terms  a  that  would  satisfy  the  condition  that: 


- ¥ 

(match  afCy  a..b.(T(Ki,ai,\a2.aa2))})  a&C  a 


This  implies  that  F(_L)  =  _L  and  we  know  that  _L  G  CFo(Kind). 

-  Consider  any  other  S.  We  will  show  that  F(S)  satisfies  the  conditions  in  Defini¬ 
tion  C.2.10  and  hence  belongs  to  CFo(Kind).  F(S)  is  defined  as  the  union  of  min( Kind) 
with  the  set  of  pure  terms  a  such  that 

- ¥ 

(match  a.{Cjf  b  (T(Ki,  a,i,  \ot2-a  (*2))})  a&C  a 


Since  C  is  a  candidate,  the  terms  a  must  be  strongly  normalizing. 

To  see  that  the  set  is  closed  under  reduction,  suppose  a\>  a'.  Since  C  is  a  candidate  we 
have  that  (match  a.{. . .})  a'  G  C  a.  Moreover,  we  have  that  C  a  =  C  a! .  Therefore, 
a!  is  also  in  the  generated  set. 

Suppose  a  is  a  neutral  term  and  for  all  a!  such  that  a  >  a1,  we  have  that  a1  belongs  to 
this  set.  We  have  to  prove  that  a  belongs  to  this  set.  This  implies  that  we  must  prove: 

- ¥ 

(match  a.{Cu  a  b.(T(Ki,ai,  \a2.aa2))})  a  £  C  a 
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Since  a  is  a  neutral  term,  the  above  term  does  not  have  a  redex  at  the  head.  From  the 
induction  hypothesis,  we  get  that  ^  4/  c  B,  ^0)  's  a  candidate 

and  therefore  closed  under  reduction.  Moreover,  the  b,  arc  strongly  normalizing.  We 
can  now  consider  all  possible  redices  and  prove  by  induction  over  u(bf)  that  the  above 
condition  is  satisfied. 

•  k  =  Elim[fi/,'u](r){/F}  where  k!  =  lnd(j  :  Kind){^}.  First  note  that  C^(n')  is  a  can¬ 

didate  by  induction  and  gives  rise  to  a  well  founded  order  on  CWo(Kind).  We  will  do 
induction  on  this  order.  Suppose  Cjj( n)  =  G(C^(n')).  We  will  show  that  for  all  sets  S 
belonging  to  the  order  generated  by  k/,  and  for  all  pure  terms  b,  we  have  that  G(S)  G 
C'lZ(u)tc-  For  the  non-recursive  case,  the  proof  is  immediate.  For  the  recursive  case,  con¬ 
sider  G(pred(b))  (Ku  Ki))-  Note  that  pred (6)  belongs  to  the  same  order.  The 

required  result  follows  now  by  doing  induction  over  the  structure  of  n,  and  applying  the 
induction  hypothesis  to  G(pred(6)). 

□ 

Definition  C.2.54  Suppose  A  is  a  context  and  K,  and  U  are  a  mapping  and  an  interpretation.  We 
say  that  K,  and  U  are  adapted  to  A  if: 

•  Mz  G  A,  we  have  that  JC(z)  is  an  arity  and  •  F  JC(z)  :  Kscm. 

•  Vj  G  A,  we  have  tliatU(j)  G  CTZ(A(j))/c. 

•  Va  G  A,  we  have  thatU(a)  G  Cy(A(a)). 

C.2.8  Interpretation  of  abstractions 

We  get  a  bunch  of  lemmas  that  state  that  an  abstraction  at  the  type  level  belongs  to  the  correspond¬ 
ing  kind.  The  proof  of  each  of  these  lemmas  is  straightforward  and  follows  in  a  similar  way.  We 
will  show  the  proof  for  only  one  of  the  lemmas. 

Lemma  C.2.55  Let  A  F  A  a  :  k.t  :  Fla  :  k.  k\  be  a  judgment  and  KL  and  U  be  a  mapping  and  a 
candidate  interpretation  adapted  to  A.  We  have  C^(Xa :  k.t)  G  Cjj(Tla  :  n.  K\)  if  and  only  if  for 
all  pure  terms  a  G  C^(k),  we  have  that  Cjj  a.a  (T)  e  CU,a:a(K l)- 
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Lemma  C.2.56  Let  A  b  A j  :  u.t  :  II  j  :  u.  At  be  a  judgment  and  1C  and  U  be  a  mapping  and  a 
candidate  interpretation  adapted  to  A.  We  have  C^(Xj  :u.t)  G  :  u.  At)  if  and  only  if  for  all 

reducibility  candidates  C  G  C1Z(u)jc  we  have  that  C}f  j.c(t)  G  j.q(k)  . 

Lemma  C.2.57  Let  A  b  A z:  Kscm.  r  :  Hz :  Kscm.  At  be  a  judgment  and  K,  and  U  be  a  mapping 
and  a  candidate  interpretation  adapted  to  A.  We  have  Cy(Xz  :  Kscm.  r)  G  Cy(Hz  :  Kscm.  «)  if 
and  only  if  for  all  u  G  arity(V,  Kind)  we  have  that  C^(t)  G  Cff’z'u(if). 

Proof  By  definition  C^(Xz :  Kscm.  r)  =  C^(t).  Similarly 

Cy{Hz:  Kscm.  At)  =  flUigarjty^u  Kind  )^u'Ul  (K)-  The  ;/Part  follows  directly  from  the  definition. 
For  the  only  if  suppose  that  C^(t)  G  C^fz'u{n)  for  all  antics  u.  This  implies  that  Cjj(r)  G 

nmearity(u,Kind)Ci":Ul(K)-  This  imPlies  that  cu  (r)  G  cu  (Uz:  Kscm- K)-  D 


C.2.9  Interpretation  of  weak  elimination 

For  this  section  At  =  lnd(j  :  Kind){/t}.  Suppose  also  that  C  G  CR(k 

Lemma  C.2.58  Suppose  a  G  Cjj(i t).  We  have  then 


Kind) ye  and  r*  G 


(match  a.{T(/tj,  7y,  Aa2-ct  a^)})  a  G  C  a 


Proof  Follows  immediately  from  the  definition  of  Cjj(n).  □ 

Lemma  C.2.59  Let  A  b  Elim  At,  h\]{t){t'}  :  m  be  a  derivable  judgment  where  n\  is  a  kind. 
Suppose  /C  is  a  mapping  and  U  is  a  candidate  interpretation  adapted  to  A.  IfCjj(r)  G  C^(k)  and 
Cyfrf)  G  At  1 .  ctor  (i,  At))),  then  we  have 

Cu(E\\m[K,K i](t){t'})  g  Cjj (Ati ) 


Proof  Follows  now  from  the  previous  lemma.  □ 

C.2.10  Interpretation  of  constructors 

For  this  section,  suppose  I  =  At  =  lnd(j  :  Kind){At}.  Also,  suppose  C  G  CTZ{I  — >  Kind)*;- 
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Lemma  C.2.60  For  all  i,  Co (i)  G  C^(ni). 

Proof  We  know  that  k,  is  of  the  form  UX :  A.  j.  Suppose  B  <G  .  cKy)  {X  :A).  Then  we  need 
to  prove  that  Co(i)  B  G  Cjj(I).  This  means  that  we  need  to  prove  that 

(match  a.{T(Ki,ai,  X a2.a  a2j})  (Co(i)  B)  G  C  (Co (i)  Z?) 

where  a*  belongs  to  the  appropriate  candidate.  This  implies  that  we  need  to  prove  that 
T  («j,  ai,  Aa2.  match  a.{.  ,.}q2)BgC  (Co(i)  5) 

This  follows  directly  by  an  induction  over  the  structure  of  □ 

C.2.11  Invariance  under  (3  reduction 

In  this  section,  we  show  that  the  interpretation  of  kinds  remains  invariant  under  (3  reduction. 

Lemma  C.2.61  Let  n  be  a  well  constructed  kind  of  schema  u  under  a  mapping  1C  and  candidate 
interpretation  U.  If  k  \>p  tf ,  then  k'  is  well  constructed  of  schema  u  under  1C  and  U,  and  C^(k)  = 

<£(*')• 

Proof  The  proof  is  by  induction  over  the  structure  of  n.  Most  of  the  cases  follow  directly  from 
the  induction  hypothesis.  We  will  only  consider  fi  reductions  at  the  head. 

•  k  =  (Xcr.Ki.  k2)  t.  By  definition, 

Cu({\or. k,i.k2)  t)  =  Cy( Xa-.K1.K2)  Cu(t) 

Again  by  definition  this  is  equal  to  Cy  a-ciC(T)(K 2)-  By  proposition  C.2.48  this  is  equal  to 

C^{[t/o\k2) 

•  k  =  (Xj  \u\.  «i)  k2.  By  definition, 

cu((^3:u  i-«t)  k  2)  =  Cy(Xj  :u\.  Ki)  Cu(k2) 
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By  lemma  C.2.53  we  have  that  Cjf  ( n2 )  6  C1Z(ui)/c .  Therefore,  we  get  that 


CuiiXj-.ux.m)  k2)  =  CJj,ck(k2)(« i) 

By  proposition  C.2.49  this  is  equal  to  Cy{[n2/ j]ni). 


□ 


C.2.12  Invariance  under  r/  reduction 

In  this  section,  we  show  that  the  interpretation  remains  the  same  under  //  reduction.  The  unmarked 
terms  ||  k  ||  are  defined  in  Section  C.1.1. 

Lemma  C.2.62  Let  n  be  a  well  constructed  kind  of  schema  u  under  a  mapping  K,  and  candidate 
interpretation  U.  If  n  k! ,  then  k'  is  well  constructed  of  schema  u  under  /C  and  U,  and  C^{n)  = 
Cu(k'). 

Proof  The  proof  is  again  by  induction  over  the  structure  of  k.  We  will  consider  only  the  cases 
where  the  reduction  occurs  at  the  head. 

•  n  =  Xa:K\.  (n2  ot).  By  definition  C^-(k)  is  equal  to: 

a  e  A  i  ■>  Cy  a.a{n 2)  C^a:a(a) 

Since  a  does  not  occur  free  in  k2,  this  is  equivalent  to 

a  £  A  1 — >  C^(k2)  a, 

Since  a  does  not  occur  free  now  in  Cff(n2),  we  get  that  this  is  equivalent  to  CfA  ( n2 ) .  Note 
from  Definition  C.2. 11  that  the  domain  of  Cjf(n2)  is  A. 

•  k  =  X j:u\.  (k2  j ).  By  definition  Cjj(n)  is  equal  to: 

C  €E  CH(ui)ic  1  »  Cuj:c(K 2)  Cu,j:cti) 
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Since  j  does  not  occur  free  in  K2,  this  is  equivalent  to 


Since  C  does  not  occur  free  now  in  C^(k/)),  we  get  that  this  is  equivalent  to  C^(k 2).  Note 
from  Definition  C.2. 11  that  the  domain  of  C^(n 2)  is  C'R,(ii\  )*;. 

□ 


Lemma  C.2.63  For  all  well  constructed  kinds  k  of  schema  u  under  1C  and  U ,  we  have  Cjj(rt)  = 

<£(  Ml). 


Proof  Follows  from  the  fact  that  k  =fjvW  k  ||. 


□ 


C.2.13  Invariance  under  /  reduction 

In  this  section  we  essentially  show  that  interpretation  remains  the  same  under  large  elimination. 

Lemma  C.2.64  Let  Elim/c.  u](t){k'}  be  well  constructed  of  schema  lC(u)  under  K.  and  U.  Sup¬ 
pose  k  =  lnd(j  :  Kind)  {at}.  Suppose  G  is  the  function  used  for  the  interpretation  of  the  large 
elimination.  If  C^j{r)  E  Cjj(k),  then  for  all  C  E  C7^o(Kind)  with  Cy(r)  E  C,  we  have  that 
G(C5(k))  =  G(C). 

Proof  The  proof  is  immediate.  □ 

Lemma  C.2.65  Suppose  I  =  n  =  lnd(j  :  Kind)  {k}.  Suppose  the  constructors  of  I  are  all  small. 
Suppose  the  mth  constructor  of  I  has  the  form  IT  Y :  B.j  and  we  have  a  sequence  of  terms  h  such 

that  Co (m)  b  E  Cft(I).  Then  we  have  that  bi  FCK  .  n  -  {Bf\. 

v  ’  UK  '  *  w,vfc<i.yfc:6fcj:pred(Co(m)  by  lJ 

Proof  We  can  have  two  cases. 

•  pred(Co(m)  b)  f  _L 

This  implies  that  pred(Co(m)  b)  E  C7£o(Kind).  Suppose 

S  =  CK  .  0  -  (Bj  ).  Then  we  have  that  S  is  a  candidate  of  schema  Kind. 

W,Vfc<i.yfe:6fc,j:pred(C0(m)  by  l> 

Suppose  also  that  C’  belongs  to  C'TU,  I  — >  Kind)*;  and  maps  elements  in  the  domain  of  /  — ► 
Kind  to  S.  Then  for  all  indices  i',  we  have  that  C^  rprec|(Q0(m)  A,.c,(Cj,i(KiL  A'i Ctor  (*'> J))) 
is  a  reducibility  candidate  of  Kind. 


187 


To  prove  the  lemma  we  need  to  show  that  if  for  all  indices  i 


Ti  G  ^,?:pred(Co(m)  >Ct°r(*>-0)) 

then  we  have  that  <b;//}/(Km.  Tm)  can  reduce  to  b,  by  a  head  reduction.  To  have  this,  for 
the  indices  i  ^  rn  choose  t,  as  some  variable.  For  rm  choose  the  term  that  returns  the  ith 
argument  of  the  constructor. 

•  pred(Co(m)  b)  =  _L  We  can  show  that  the  constructors  now  arc  not  recursive.  Hence  j  does 
not  occur  free  in  any  of  the  /i,s.  The  proof  for  the  previous  case  can  be  reused  here. 

□ 

Lemma  C.2.66  Let  A  F  Elim[/\.  v](t){k'}  :  u  be  a  derivable  judgment.  Let  K,  be  a  mapping  and 
U  be  an  interpretation  adapted  to  A.  Suppose  /  =  n  =  lnd(j  :  Kind){/T}.  Suppose  Cf^(j)  £  Cy(n) 
and  t  >*  Ctor  (i,  n)  A.  Also  suppose  B'  =  Xa:  I.  Elim  [k,  u] («){«/}.  We  then  have  that 

Proof  Let  G  be  the  function  used  for  interpreting  large  elimination.  Suppose  Co (i)  a  is  the 
normal  form  of  C^(t).  Then  given  the  assumptions  we  have  that: 

C%(E\\m[K,u\(T)W})  =  C£B,:G(pred(Co(i)  («) 

We  therefore  have  to  prove  that 


CK 

w,s':G(pred(Co(j)  a)) 


(a)  =  (^)) 


•  Ki  =  j  it  follows  directly. 

•  K,;  =  IT  a  K  ] .  K/)  We  have  to  prove  that 


CK 

W,B':G'(pred(CO(i)  a)),a:a  1 


a))  (a2..n)  = 


CU,a:aS^LLB'{^2^'i  «) 


Applying  the  induction  hypothesis  leads  to  the  result. 
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•  m  =  Ila :  k.  j  — >  k2  The  LHS  becomes 


Cu'($j,i,B'(K2,K'M\Y :  k.  B'(aY))))  (a2..n) 
where  Z/  =U,B'  :  G(pred(Co(i)  a)),  a  :  a\ 

By  lemma  C.2.65,  a\  belongs  to  _  prec|^Q0^,^  ^(n a:n.j).  This  implies  that  a\  Y  E 
pred(Co(i)  a).  Moreover,  by  lemma  C.2.64  G(pred(Co(i)  a))(ai  Y)  is  equal  to 
G(Cjj(n))(ai  Y)  and  which  is  in  turn  equal  to  C^(Elim[K, u](A\  Y){«/}).  The  required 
result  follows  directly  from  here  by  performing  one  head  reduction  on  the  RHS  and  applying 
the  induction  hypothesis. 

□ 


C.2.14  Kinds  invariant  on  their  domain 

Definition  C.2.67  Let  A  b  k  :  u  be  a  derivable  judgment  and  1C  and  U  be  a  mapping  and  an 
interpretation  adapted  to  A.  We  say  (k,  u,  A,  JC,U)  is  invariant  if: 

•  u  =  Kind  and  for  all  tf  such  that  k  t>*  k!  ,  we  have  that  C^(k)  =  C5(k'); 

•  u  =  Ila;:  k\.u\  then  for  all 'derivable  judgments  A  b  r  :  K\  and  Cjj  (r)  E  C^(ki),  we  have 
that  (k  t,  [r/a]ui,  A,JC,U)  is  invariant; 

•  u  =  n  j  :u\.U2  then  for  all  derivable  judgments  A  b  K\  :  u\,  we  have  that 
(k  ki,  [rt\/j]u2,  A,  1C,U)  is  invariant; 

•  u  =  z  and  we  have  that  (JC(n) ,  K,(u) ,  /C( A) ,IC:U)  is  invariant. 

Lemma  C.2.68  Let  A  b  K\  :  Kind  and  A  b  k2  :  Kind  be  two  derivable  judgments  and  KL  and  U 
be  a  mapping  and  an  interpretation  adapted  to  A.  If  (k i,  Kind,  A,  JC,IL)  and  (k2,  Kind,  A,  IC,U) 
are  invariant  and  K\  =0Vl  k2,  then  C^(n i)  =  C^(k2). 

Proof  We  know  that  there  exists  a  B  such  that  ||  K\  ||  \>*B  and  ||  k2  ||  \>*B.  This  implies  that 
there  exists  a  n\  and  a  k'2  (lemma  C.1.4  and  C.1.14)  such  that  K\  t>fji  n\  and  |  k\  ||  >*B.  Similarly, 
k 2  k!2  snd  ||  «2  II  From  here  we  get  that 

Cu(K  t)  =  CuiKi)  =  2)  =  Cjj(n2) 
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□ 

Proposition  C.2.69  If  (\t / o/\k,u,  A,1C,U)  is  invariant,  and  also  A  b  (Act  :  k\ .re)  t  :  u,  then 
((Aa  \K\ .re)  t,  u,  A,  1C, U)  is  invariant. 

C.2.15  Interpretation  of  large  elimination 

Lemma  C.2.70  Let  A  b  Elim[re,  u](t){k'}  :  u  be  a  judgment.  Suppose  I  =  re  =  lnd(j  : 
Kind) {/?}.  Let  K.  and  U  be  a  mapping  and  an  interpretation  adapted  to  A.  Suppose 

1.  cftir)  g 

2.  for  all  i,  (re(,  ^/(rei,  u),  A,  1C,  U)  is  invariant. 

Then  we  have  that  (Elim [re,  u]  (r){re'},  u,  A,  1C,  U)  is  invariant. 

Proof  Suppose  rei  =  Elim  re,  u](t){k/}.  Suppose  we  arc  given  a  sequence  of  terms  A  of  the 
proper  type  so  that  rei  A  is  in  Kind.  To  show  the  invariance,  we  have  to  show  that  if  rei  A  >*  k-2, 
then  C[j  ( re  ]  A)  =  Cy(n 2).  We  will  reason  by  induction  on  C^(t)  over  the  order  defined  by  I. 

•  If  the  term  Cjj(r)  can  not  be  reduced  to  a  term  of  the  form  Co  (i)a,  then  it  is  minimal  with 
respect  to  the  order  defined  by  I.  Then  re 2  is  necessarily  of  the  form 

Elim  [re',  u'}(r'){td'}  A!  and  we  have  that  the  interpretation  of  both  rei  ,4  and  K2  is  Cano  (Kind). 

•  Suppose  the  term  Cjj  ( r )  can  be  reduced  to  a  term  of  the  form  Co (i)a,  but  r  is  not  reduced 
to  a  term  of  the  form  Ctor  (i.  I)C.  Then  0:9  is  again  of  the  form 

Elimfre'",  ■///] (t'){ k" }  A'.  By  definition,  we  have  that 

B 1  =  Cfi(K,  A)  =  (“)T 

s2  =  (S)A') 

where  B'  =  A Y  :  I.  Elim[re,  re](r){re'},  and  B"  =  A Y  :  I'.  Elim[re///,  u'](t'){k"}.  It  is 
evident  that  B2  is  a  reduct  of  B\ ,  and  therefore  we  need  to  prove  that  (B\.  Kind,  A,  1C, U)  is 
invariant. 

This  follows  by  an  induction  over  the  structure  of  re*  and  by  using  the  condition  2.  The  non¬ 
recursive  cases  follow  directly.  For  the  recursive  case,  we  use  lemma  C.2.65  to  show  that  B' 
is  applied  to  a  smaller  argument  with  respect  to  the  order  defined  by  I. 
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We  arc  left  with  the  case  when  r  reduces  to  a  term  of  the  form  Ctor  if.  I)C.  In  going  from 
K\  A  to  K‘2 ,  we  will  now  have  a  i  reduction.  The  sequence  of  reductions  is  now 


k i  A  t>*  Elim[«;, 'u](Ctor(i,/)^*){K/} 

><.  j, 1,^(1*,  B’)  ( B))A 

>*  k2 

The  first  reduction  does  not  change  the  interpretation  since  we  arc  reducing  only  a  type.  By 
lemma  C.2.66,  the  second  does  not  change  the  interpretation.  Finally,  as  above,  we  can  prove 
that  the  result  of  the  t  reduction  is  invariant  over  Kind. 


□ 


C.2.16  Instantiation  of  contexts 

Definition  C.2.71  Let  A  be  a  well  formed  context.  Let  0  be  a  context  and  6  be  a  mapping  from 
variables  to  tenns  such  that  VX  f  A,  <f{X)  =  X. 

We  say  that  (0,0)  is  an  instantiation  of  A  if  for  all  variables  X  6  A,  we  have  that  0  F 
f(X)  :  0(A(X)). 

Lemma  C.2.72  Let  A  h  A  :  B  be  a  derivable  judgment  and  (0,  0)  an  instantiation  of  A.  Then 
0  F  f(A)  :  f(B). 

Proof  By  induction  over  the  structure  of  A.  □ 

Definition  C.2.73  (Adapted  instantiation)  We  say  that  an  instantiation  (0,  0)  is  adapted  to  a 
context  A  if: 

•  for  all  a  <E  A,  (f>(a)  <E  CQan()(0)(^(A(a)))> 

•  for  all  j  £  A,  4>(A(j)),  0, 0,  Cano(0))  is  invariant; 

•  for  all  z  6  A,  Kscm,  0,  0,  Cano(0))  is  invariant  and  4>(z)  is  an  arity. 

Definition  C.2.74  Suppose  A  F  n  :  u  is  a  derivable  judgment.  We  say  that  all  instantiations  of 
(n,u,  A)  are  invariant  if  for  all  instantiations  (0,0)  adapted  to  A  and  for  all  interpretations  U 
adapted  to  0,  we  have  that  (0(k),  f(u),  0,  0,(f )  is  invariant. 
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C.2.17  Kind  schema  invariant  on  their  domain 


Definition  C.2.75  Let  Ah  u  :  Kscm  be  a  derivable  judgment  and  1C  and  U  be  a  mapping  and 
an  interpretation  adapted  to  A.  We  say  that  (u,  Kscm,  A,  1C, Id)  is  invariant: 

•  if  u  =  Kind,  then  (■ u ,  Kscm.  A,  /C. Id)  is  invariant; 

•  ifu  =  Tla:n\.u\,  then  it  is  invariant  if  and  only  if  («i,Kind,  A,  1C,  Id)  is  invariant  and  for 
all  terms  r  such  that  A  h  t  :  K\  is  derivable  and  Cjj(r)  €  Cjj(ni),  we  have  that 
([t/o\ui  ,  Kscm ,  A,  1C, Id)  is  invariant; 

•  ifu  =  Uj:u\.  it  2,  then  it  is  invariant  if  and  only  if  (u\,  Kscm ,  A,  1C, U)  is  invariant,  and  for 
all  kinds  k  such  that  A  h  k  :  u\  is  derivable  and  (k,u\,  A,fC,ld)  is  invariant,  we  have  that 
([n/j]u2,  Kscm,  A,  1C, Id)  is  invariant; 

•  ifu  =  z,  then  it  is  invariant  iff  (lC(z) ,  Kscm ,  A,  1C,  Id)  is  invariant. 

Lemma  C.2.76  Let  Ah  k  :  u  and  Ah  u'  :  Kscm  be  derivable  judgments.  Let  K,  and  U 
be  a  mapping  and  an  interpretation  adapted  to  A.  Suppose  u  =0^  u1,  end  {u,  Kscm.  A,  1C, Id) 
and  (v! ,  Kscm ,  A,  1C, Id)  are  invariant.  If  ( k ,  u,  A, 1C, Id)  is  invariant,  then  (k,  u’ ,  A,  1C,  Id)  is  also 
invariant. 

Proof  The  proof  is  by  induction  over  the  structure  of  u  and  if. 

•  if  u  =  v!  =  Kind,  then  it  is  trivially  true. 

•  if  u  =  u'  =  z,  then  again  it  is  trivially  true. 

•  if  u  =  IIq;  :  k\.u\  and  v!  =  Ila :  ti2-U2,  then  we  have  that  K\  =pVL  n 2  and  u\  =0Vi  u2-  By 
assumption,  we  know  that  (ki,  Kind,  A,  1C, U)  and  (K2,  Kind,  A,  1C, Id)  are  invariant.  This 
means  that  Cy{n  1)  =  Cjj(n 2).  Moreover,  A  h  r  :  k\  is  true  iff  A  h  t  :  rt 2  is  true. 
Applying  the  induction  hypothesis  now  leads  to  the  required  result. 

•  i f  a  =  Ylj :  u  1 .  u-2  and  11/  =  II j :  u\ .  u'2,  the  proof  is  similar  to  the  previous  case. 

□ 

Definition  C.2.77  Suppose  Ah  u  :  Kscm  is  a  derivable  judgment.  We  say  that  all  instantiations 
of  (u.Kscm,  A)  are  invariant  if  for  all  instantiations  (0,  <f)  adapted  to  A  and  for  all  interpretations 
U  adapted  to  0,  we  have  that  (tj)(u),  Kscm,  0, 0, Id)  is  invariant. 
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C.2.18  Strong  normalization  of  pure  terms 

Theorem  C.2.78  Let  A  b  r  :  n  be  a  derivable  judgment  and  1C  and  U  be  a  mapping  and  an 
interpretation  adapted  to  A.  Then  Cjj(r)  6  Cy{n). 

Proof  The  proof  is  by  induction  over  the  length  of  the  derivation.  The  induction  hypothesis  arc 
as  follows: 

•  if  A  b  r  :  k  and  K,  and  U  be  a  mapping  and  an  interpretation  adapted  to  A,  then  C^(t)  G 

cjj  (K); 

•  if  A  b  k  :  u,  then  all  instantiations  of  (k.u.  A)  arc  invariant; 

•  if  A  b  u  :  Kscm,  then  all  instantiations  of  (u.Kscm.  A)  arc  invariant; 

type  formation  rules  This  paragraph  deals  with  rules  of  the  form  A  b  r  :  k. 

•  abstractions  -  Follows  directly  from  the  induction  hypothesis  and  lemmas  C.2.55  and  C.2.56 
and  C.2.57. 

•  var  -  Follows  because  the  interpretation  U  is  adapted  to  the  context  A. 

•  weak  elimination  -  Follows  from  lemma  C.2.59. 

•  constructor  -  Follows  from  lemma  C.2.60. 

•  weakening  -  Follows  directly  from  the  induction  hypothesis  since  the  mapping  and  interpre¬ 
tation  remain  adapted  for  a  smaller  context. 

•  conv  -  Follows  from  the  recursion  hypothesis  and  lemma  C.2.68. 

•  app  -  All  three  cases  of  app  arc  proved  similarly.  We  will  show  only  one  case  here. 

-  A  b  t[u']  :  k.  Then  we  know  that  A  b  r  :  TIz :  Kscm.  K\  and  Abu':  Kscm  and 
[v! / z]k\  =  k.  By  the  induction  hypothesis 

cu(r)€  nui6arity(UiKind)c5’*:ttl(«i) 

Suppose  u\  =  IC(ur).  Then  we  know  that  C^(t)  €  C^,z  Ui(ki).  By  proposition  C.2.50 
we  know  that  Cjj(r)  G  Cjj([u  '/z\k i).  But Cy(r[u'})  =Cfi{r). 
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kind  formation  rules  This  paragraph  deals  with  rules  of  the  form  Ah  k  :  u. 

•  product  -  All  the  product  formation  rules  arc  proved  in  the  same  way.  We  show  only  one 
case  here. 

-  Consider  the  following  formation  rule 

A,  z:  Kscm  h  k  :  Kind 
A  h  Hz :  Kscm.  k  :  Kind 

We  have  to  prove  that  for  all  instantiations  (0,  ([>)  we  have  that 
{Hz  :  Kscm.  4>(k),  Kind,  0,  0,Z7)  is  invariant.  This  implies  that  we  must  prove  that 
if  k  D>  k',  then  C^{Hz  :  Kscm.  (/>(«))  =  Cf^iHz  :  Kscm.  </>(«/)).  By  the  induction 
hypothesis,  for  all  instantiations  (0,  0;  £ :  arity  (u,  Kind))  we  have  that 

(0;  z:ar\ty{u,  Kind)(ft),  Kind,  0,  0,£4) 

is  invariant.  This  implies  that  if  k  l>  n1  then 

^^laritytu.Kind),  ,  _  ,,,z:arity(«,Kind) , 

'-'U  \K)  ~  vK  ) 

The  required  result  follows  from  here. 

•  var  -  follows  since  the  instantiation  is  adapted. 

•  conv  -  follows  from  lemma  C.2.76. 

•  application  -  Both  of  the  applications  arc  proved  similarly  and  follow  directly  from  the  in¬ 
duction  hypothesis.  We  will  show  only  one  case  here. 

-  If  A  h  aci  «2  :  [k2 /.)]«„  then  given  0,  <p,  and  Zi,  we  must  prove  that 

{4>{n\  k-2 ) ,  4>{[k,2 / j]u) ,  0,  %,U)  is  invariant.  But  by  the  induction  hypothesis  we  know 
that  {(j){ni),  4>{Hj  :  iti. «),  0, 0,Z7)  is  invariant  and  A  h  K2  :  u\.  By  lemma  C.2.72 
0  h  (f){ K‘2 )  :  d)(  u\ ).  This  leads  to  the  required  result. 

•  ind  -  Suppose  I  =  lnd(j  :  K i n d ) { /T} .  Note  that  Cjj(I)  depends  only  on 

Cuj:S,A’-.c,B':CO(i)^j’I^Ki,A',B'^  where  5  G  Po(Kind)  and  C  G  CK{I  ->  Kind)*;.  By 
induction  on  the  structure  of  k, ,  we  can  show  that  this  is  invariant.  This  implies  that  if  nr  [> 


194 


then  the  interpretation  remains  the  same.  If  I  [>  I',  then  for  some  i,  n,  D>  From  here  we 
can  deduce  that  if  I  D>  I1,  then  Cff(I)  =  Cy(Ir). 


•  large  elim  -  Follows  from  lemma  C.2.70. 

•  abstraction  -  Both  of  the  abstractions  are  proved  similarly.  So  we  will  show  only  one  of  the 
cases. 

-  A  F  Xar.Ki.  K2  :  Fla:  K\.  u.  Wemustprove  that  ((j)(Xa:  n\.  K2),  u),  0,  ®,U) 

is  invariant,  given  0,  0,  and  U.  This  implies  that  if  0  h  r  :  0(n\ )  and  r  belongs  to 
the  appropriate  candidate,  then  we  must  have  ( 0(Aa :  n  1 .  K2)  r,  \r/a](j)(u),  0, 0.Z7)  is 
invariant.  By  proposition  C.2.69  we  must  prove  that 

([i~/a\<t>(K2),  [r/a\(t)(u),e,$,U) 

is  invai  iant.  But  (0,  a  :  r)  is  an  instantiation  that  is  adapted  to  (A,  a  :  n  1 ) .  Applying 
the  induction  hypothesis  now  leads  to  the  result. 

schema  formation  rules  This  paragraph  deals  with  rules  of  the  form  A  F  u  :  Kscm . 

•  it  =  Kind  follows  directly. 

•  u  =  z  follows  since  the  instantiation  is  adapted. 

•  u  =  II j  :  u  1 .  u-2  Given  0,  <p,  and  U  we  have  to  prove  that  (0(11 j  :  U1.U2),  Kscm,  0, 0. U) 
is  invariant.  By  the  induction  hypothesis,  we  know  that  (0(u ] ),  Kscm,  0, 0. U)  is  invaiiant. 
The  induction  hypothesis  also  says  that 

([0,j  :  k]{u2),  Kscm,  0, 0,Z/)  is  invaiiant.  We  also  know  that  A  F  k  :  4>{u  1)  and 
(k,  4>(u  1),  0, 0. U )  is  invaiiant  since  the  instantiation  is  adapted.  This  implies  that 

(4){[k / j]u2) ,  Kscm,  0,  %,U)  is  invaiiant. 

•  u  =  Fla :  n  ] .  a  1  the  proof  is  very  similar  to  the  above  case. 

□ 


Corollary  C.2.79  Ifr  is  a  well  formed  type,  \  r  |  is  strongly  normalizing. 
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Proof  Since  r  is  well  formed  we  have  that  Ah  t  :  k.  We  only  need  to  construct  an  interpre¬ 
tation  and  a  mapping.  For  the  interpretation,  let  U(a)  =  a  for  every  type  variable.  Then  we  get 

Cu(T )  =M- 

We  can  build  the  rest  of  U  and  IQ  as: 

•  if  A  =  •  then  U (j )  =  Cano(Kind)  and  IC(z)  =  Kind  for  all  variables  j  and  z; 

•  if  A  =  A'  ,a:K  then  return  the  U'  and  IQ'  associated  with  A'; 

•  if  A  =  A ' ,j  :  u  then  U  =  U' .  j  :  C  and  IQ  =  K,' ,  where  C  £  ClZ(u))c  and  K,'  and  U'  are 
associated  with  A'; 

•  if  A  =  A',  z  :  Kscm  then  IQ  =  IQ',  z  :  Kind  and  U  =  U’  where  IQ ’  and  U’  are  associated 
with  A'. 

□ 

C.2.19  Normalization  of  terms 

In  this  section,  we  use  an  encoding  that  maps  all  well  formed  terms  to  types.  This  encoding 
preserves  the  number  of  reductions.  The  idea  is  similar  to  that  of  Harper  et  al  [HHP93]. 

The  encoding  uses  two  constants,  hi  is  a  kind  and  B  is  a  type.  *  is  a  variable  that  is  never  used, 
it  is  a  wild-card. 

A  :  Kind 
B  :Hj  :  Kind.  J 
*  unused  variable 

The  encoding  for  Kscm  is  as  follows: 

S'(Kscm)  =  Kscm 
[/(Kscm)  =  Kind 
/i(Kscm)  =  A 

The  encoding  for  schemas  is  as  follows: 
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[/(Kind)  =  Kind 

U  (Ila  :k.u)  =  Ila  :K(k).U  (u) 

U (Ilj  :u\.  112)  =  Ilj  :  U («i).  II ctj  :  K(u\).  U (112) 

U(z)=z 

K(K\nd)  =  A 

K (Ila :  k.  u)  =  Ila :  K (k)  .  K ( u ) 

K(Hj :  u\.  U2 )  =  II  j:U  (u\).  II  ctj  :  K(u\).  K{u2) 

K(z)  =jz 

T(Kind)  =  B  A 

T(Ha:  k.u )  =  B[A  — >  Ha:  K(n).  A  — >  *4] 
T(«)(Aa:lir(re).r(ii)) 

T(IIj  : «!.  112)  =  B[A  —>  Hj :  U (u\).  Haj  :K(u\).A  — >  A] 
Tiu^Xj-.Uiu^.Xaj-.Kiu^.T^)) 

T(z)  =  az 

The  encoding  for  kinds  is  as  follows: 


K(j)=j 

K{Ha:  K\.  K2)  =  Ila:  K(n\).  K(k 2) 

K(Hj  :u.k)  =  n j :  U(u).  Haj  :  K{u).K{n) 

K(Hz:  Kscm .  k)  =  Hz :  Kscm .  Ilj. :  Kind .  IIa2  :A.K(k ) 
K  ( A  j  :u.  k)  =  Xj  :U(u).  X  aj  :  K  (u) .  K  (k) 
K(Xa:n\.  K2)  =  Xa:K(n\).  K(k2) 

K(k  t)  =  K(k)  T(t) 

K{k  1  k2)  =  K{k  1)  K(k2)T{k2) 

AT(lnd(j :  Kind){£})  =  lnd(j :  Kind){A  («)} 

AT(Elim[K,  it](T)-{V}j  =  Elim[/\  (k),  U (u)](T(t)){AT(k/)} 
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T{j)  =  otj 

T(Ila:Ki.  H2)  =  B[A  — >  Tlor.K(ni).  A  — >  A] 
r(Ki)(Aa:A>i).T(K2)) 

T(Uj  :u.  k)  =  B[A  ->  Uj  :  [/('«).  n^- :  AT(tx).  .4  -»•  A] 
T(u)(Xj  :  C/(«).  A  aj:K(u).T(k)) 

T(Jlz :  Kscm.  k)  = 

B\U.z : Kscm.  : Kind. IIo^  :A.  A  —>  A] 

(A 2 :  Kscm.  A jz  :  Kind.  \az  :  A.  T(k)) 

T(\j:u.K ) = 

Aj :  C/(m).  Aa,  :  A(A).  (A* :  A  T(ac))T(u) 

T(Aa  :n\.  K2)  =  Xct.K(ki).  (X* :  A.  T(k2))T(ki) 

T(k  t)  =  T(k)  T{t) 

t(k  1  K2)  =  r(«1)[ii'(K2)]T(/C2) 

T(lnd(j  :Kind){K})  = 

6[(Kind  -»•  A  -»•  (4  -»•  . . .  -»•  A)  -»•  4)  -»•  4] 

(Aj :  Kind.  Xaj  :A.  XY :  {A  ^  A).{Y  T(k-))) 
T(Elim[«,  u]  (t){/c'})  = 

Elim[AT(«) ,  (A* :  K(k).  K(u))\ (T(r)) 

{(A*  :4.  X*:A.  r(K'))T(K)r(4} 

The  encoding  for  types  is  as  follows: 
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T(a)  =  a 

T(Xa:n.  t)  =  A a:K(n).  (A* :  A.  T(r))T(/c) 

T(r1r2)  =  T(r1)T(r2) 

T{Xj  :u.t)  =  A j  :U(u).  A ay  :K(u).  (A*  \A.  T(t))T(u) 
T(t[k})=T(t)[K(k)}T(k) 

T(Xz:  Kscm.  r)  =  Az:  Kscm.  Xjz  :  Kind.  A az:A.  T(r) 

T{t[u\)  =  T{t)[U(u)][K(u)}  T(u) 

T(Ctor  (i,  K))  =  (A *:A.  Ctor  (i,  K(k)))T(k) 

T(Elim[K,/ci](r){r})  = 

Elim[/i(ft),  K (ki)](T(t)){(X* :  A.  X*:A.  T  (ri))T  (k)T  (k\)} 

We  have  to  define  a  similar  transformation  on  contexts: 

T(-)  =  •,  A:  Kind,  B :  Ilj :  Kind,  j 

r(A,a:/c)  =  r(A),a:X(«) 

F(A  ,j:u)  =  T(A),j:U(u),aj:K(u) 
r(A,z:Kscm)  =  r(A),2::Kscm,jz:Kind,a^:Al 

C.2.20  Coding  and  reduction 

In  this  section  we  state  lemmas  that  prove  that  the  coding  preserves  the  number  of  reductions.  We 
omit  the  proofs  since  they  follow  by  a  straightforward  induction  over  the  structure  of  terms. 

Lemma  C.2.80  For  all  well  typed  terms  A,  if  A  \>p  A',  then  we  have 

T(A)  T(A') 

K(A )  >*  K(A') 

U(A)  \>*p  U(A') 

Moreover ;  if\\  A  ||  \>pA\,  then  there  exists  A%  such  that  ||  ^42  ||=  A\  and  \  T{A)  |  >1+  |  T(Af)  \. 
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Lemma  C.2.81  For  all  well  typed  terms  A,  if  A  o,  A',  then  we  have 


T{A)  >j+  T(A') 

K(A)  >*  K(A') 

U(A)  >*  U(A') 

Moreover,  if  ||  A  ||  \>,.0A\,  then  there  exists  A 2  such  that  ||  A2  ||=  A\  and  \  T(A)  |  >1+  |  T(Af)  |. 
Lemma  C.2.82  For  all  well  typed  terms  A,  if  A  o  f;  A’,  then  we  have 

T{A)  T(A’) 

K(A)  K(A') 

U(A)  >*pi]  U(A’) 

C.2.21  Coding  and  typing 

In  this  section  we  show  that  the  coding  of  a  well  typed  term  is  also  well  typed.  For  this  we  need  to 
prove  that  the  coding  preserves  /3rjL  equality.  This  requires  a  confluent  calculus.  Therefore,  we  use 
the  unmarked  terms  from  Section  C.1.1.  We  extend  the  coding  to  unmarked  terms  by  defining: 

U(-)  =  - 

K(_)  =  _ 

T(_)  =  _ 

It  is  now  easy  to  prove  by  a  straightforward  induction  on  the  structure  of  terms  that  the  follow¬ 
ing  lemma  holds: 

Lemma  C.2.83  Suppose  A  b  A  :  B  and  B  f  Ext.  Then  we  have  that 

T(A)  F  T(A)  :  K(B)  andT( A)  F  K(B)  :  Kind 

T(A)  F  K(A)  :  U(B)  and  T(A)  F  U{B)  :  Kscm  if  defined 

T(A)  F  U(A)  :  S{B)  andT(  A)  F  S{B)  :  Ext  if  defined 

Corollary  C.2.84  Suppose  A  F  A  :  B  and  B  f  Ext.  Then  \  T (  A)  \  is  strongly  normalizing. 
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C.2.22  Normalization  of  unmarked  terms 


Lemma  C.2.85  For  all  well  typed  terms  A,  we  have  that  |  ,4  |  is  strongly  normalizing  for  /3t]Lq 
reduction. 

Proof  Since  there  can  not  be  an  infinite  sequence  of  rj  reductions  and  we  can  delay  //  reductions, 
we  need  to  prove  the  normalization  for  /3lq  reductions  only.  Suppose  ||  A  ||  is  not  normalizing  and 
there  exists  a  sequence  A\. . .  A^. . .  such  that  A%  >pl0  Ai+\  and  Ao  =||  .A  ||.  By  lemma  C.2.80 
and  C.2.81,  we  get  that  there  exists  a  sequence  of  terms  A\  . . .  ,4  ■ . . .  such  that  ||  A[  ||=  Ai  and 
I  T{A'f)  |  \T(A'i+1)\  and  also  |  T(A)  |  O1^  |  T(A'1)  |.  This  implies  that  |  T(A)  |  is  not 

strongly  nomializing  which  is  a  contradiction.  □ 

C.2.23  Normalization  of  all  terms 

Lemma  C.2.86  Suppose  A  \>pL  B.  Then  ||T(2l)||  \>1^  ||T(.B)||. 

Proof  By  induction  over  the  derivation  of  A  \>pL  B.  Note  that  in  taking  a  term  A  to  T(A),  all  the 
terms  C  that  appeal-  as  annotations  at  lambda  abstractions  are  duplicated  with  the  corresponding 

T(C).  □ 

Lemma  C.2.87  Suppose  A  F  A  :  B.  Then  A  is  strongly  normalizing. 

Proof  We  only  have  to  prove  normalization  for  ft.  reduction.  By  lemma  C.2.86,  if  A  is  not 
normalizing,  then  ||  T(A)  ||  is  also  not  normalizing.  But  by  lemma  C.2.83  we  have  that  T(A)  F 
T(A)  :  K(B)  which  implies  ( lemma  C.2.85)  that  ||  T(A)  ||  is  strongly  normalizing.  □ 

Theorem  C.2.88  (Strong  normalization)  All  well  typed  terms  are  strongly  normalizing. 

Proof  Follows  from  lemma  C.2.87.  □ 


C.3  Church-Rosser  property 

The  proof  is  structured  as  follows: 

•  We  first  prove  that  a  well  typed  term  A  in  ft.  normal  form  has  the  same  rj  reductions  as  ||  A  ||. 

•  From  here  we  know  that  if  A  and  A ’  are  in  normal  form,  then  ||  A  ||  and  |  A'  |  are  equal.  We 
then  show  that  the  annotations  in  the  A-abstractions  are  equal. 
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C.3.1  Structure  of  normal  forms 


Lemma  C.3.1  All  well  typed  dt,  normal  terms  N  have  the  following  form: 

1.  XX-.Ni.N2. 

2.  UX-.Ni.N2. 

3.  s  e  {Kind,  Kscm,  Ext}. 

4.  X  N. 

5.  lnd(X:Kind){iV}. 

6.  ctor  (i,  N)  N  where  N  is  of  the  form  5. 

7.  ElimfiV,  N2\(Ni){N}  N'  where  N  is  of  the  form  5  and  N\  is  of  the  form  4. 

Lemma  C.3.2  Let  A,  X  :  C,  A'  b  A  :  B  be  a  judgment  and  A  in  (3l  normal  form.  If  X  does  not 
occur  in  FV(B)  U  FV(A')  U  FV(\\  A\\),  then  X  <£  FV(A). 

Proof  The  proof  is  by  induction  over  the  size  of  A.  We  use  lemma  C.3.1  to  enumerate  the 
different  cases. 

•  The  case  where  .4  is  a  variable  or  a  sort  is  immediate. 

•  Suppose  A,  X :  C,  A'  b  II L  :N\.  N2  :  B.  It  follows  directly  from  the  induction  hypothesis 
that  X  does  not  occur  in  N\  and  N2. 

•  Suppose  A,X  :C,  A'  b  A Y  :  N2  :  B  and  B  =  UY  :  Ni.A!.  We  know  that  A,  X  : 

C,  A'  b  Ni  :  s  and  therefore  X  f  FViNf.  Also  B  >*  UY :  N[.  A "  and  A,X:C,A\Y: 
Ni  b  N2  :  A".  Since  X  j  FV ( A ")  U  FV (Ni),  we  can  apply  the  induction  hypothesis  and 
therefore  X  FV(N2). 

•  Suppose  A,  X  :  C,  A'  b  Y  N  :  B.  This  implies  that  A,  X  :  C,  A'  b  Y  :  UZ :  Ai.  A2  and 
A,  X  :C,  A'  b  Ni  :  Ai.  From  lemma  C.1.32  and  C.1.17  we  have  that  A,  X  :  C,  A'  b  Y  : 
UZ  :  A3.  A4  where  X  does  not  occur  free  in  A3  and  A3  =pni  Ai  and  A4  =pni,  ^2-  From 
here  we  can  show  that  A,  X  :C,  A'  b  N\  :  A3.  We  can  now  apply  the  inductive  hypothesis 
to  show  that  X  f  FV  (Ni).  Iterating  in  this  way,  we  can  show  that  X  f  FV  (Ni). 
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•  Suppose  A,  A  :  C,  A'  b  lnd(Y  :  Kind){IV}  :  B.  Follows  directly  from  the  induction 
hypothesis  that  X  ^  F  V  ( Nt ) . 

•  Suppose  A,  X  :  C,  A'  b  Ctor  (*,  I)  N  :  B.  Follows  directly  from  the  induction  hypothesis 
that  X  FV (I).  We  can  then  show  as  above  that  X  ^  FV ( A* ). 

•  Suppose  A,  A  :  C,  A'  b  Elim[A,  Ai](A2){A}  A'  :  B.  Since  A,  A  :  C,  A'  b  A  :  Kind, 

it  follows  from  the  induction  hypothesis  that  X  ^  FV ( N ).  Similarly,  since  A,  X  :C,  A'  b 
Ni  :  Kscm,  or  A,X:C,  A'  b  iV,  :  A  —  Kind,  it  follows  that  X  FV{N1).  Similarly  we 
can  prove  directly  from  the  induction  hypothesis  that  X  ^  FV (A2)  U  FV ( A ).  Finally,  as 
above  we  can  prove  that  A  f  FV(N').  □ 

Corollary  C.3.3  Let  A  b  A  :  B.  If  A  is  in  normal  form,  then  ||  A  ||  is  also  in  normal  form. 

Proof  We  must  show  that  ||  A  ||  does  not  contain  any  i)  reductions.  The  interesting  case  is  when 

A  is  of  the  form  XX  :  N{ .  Ab  X.  We  want  to  show  that  if  X  FV (||  ||),  then  X  ^  FV ( Ab ). 

Since  it  is  well  typed  we  know  that  A  b  XX  :  Ab .  Ab  X  :  liX  :  N\ .  C.  We  have  that  X  f 

FV  (FLY  :  N\ .  C ).  From  here  we  get  that  A,  X  :  N\  b  Ab  :  FI  A'  :  N\ .  C.  This  implies  that  if 

X  ^  FV(\\  Ab  ||),  then  X  £  FV(N2).  □ 

C.3.2  Church-Rosser 

Theorem  C.3.4  (Church-Rosser)  Let  A  b  A  :  B  and  Abb':  B  he  two  derivable  judgments. 

If  A  A',  and  if  A  and  A'  are  in  normal  form,  then  A  =  A! . 

Proof  We  know  that  ||  A  ||  and  |  A'  |  are  in  normal  form.  Since  the  unmarked  terms  are  confluent 

we  have  that  ||  A  ||=||  A'  ||.  The  proof  is  by  induction  over  the  structures  of  A  and  A' . 

•  The  case  when  A  =  A'  =  s  or  A  =  A'  =  a  variable  is  immediate. 

•  Suppose  A  =  XX :  Ab .  Ab  and  A'  =  XX :  N[.  N'2.  We  know  that  B  =/3VL  FLY :  N\.  A^  =pVL 
FLY  :  N[.  ,4b  This  implies  that  Ab  =pVL  Ar[  which  implies  that  both  of  them  have  the  same 
sort.  This  implies  that  Ab  =  N[ .  We  can  now  apply  the  induction  hypothesis  to  Ab  and  N'2 
to  get  that  Ab  =  Nf 

•  Suppose  b  =  IF  A  :  Aj .  N2  and  A'  =  FLY  :  N[.N2.  Follows  directly  from  the  induction 
hypothesis. 
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•  Suppose  A  =  X  N  and  A'  =  X  N' .  We  know  that  in  the  context  A,  the  variable  X  has 
the  type  111" :  B.  A3.  Therefore  each  of  the  Nt  and  N'  have  the  same  type.  Applying  the 
induction  hypothesis  to  each  of  them  leads  to  the  required  result. 

•  Suppose  A  =  lnd(Y  :  Kind){!V}  and  A!  =  lnd(A  :  KindjjlV'}.  By  the  typing  rules  we 
know  that  A,  X :  Kind  F  TV*  :  Kind  and  A,  X :  Kind  F  N[  :  Kind.  Applying  the  induction 
hypothesis  leads  to  Nt  =  N-. 

•  Suppose  A  =  Ctor  (i,  N )  N  and  A'  =  Ctor  (i,  N')N'.  We  know  that  both  N  and  N'  have 
type  Kind.  The  induction  hypothesis  directly  leads  to  N  =  N'.  We  can  then  show  as  above 
that  Nt  =  N[. 

•  Suppose  A  =  Elim[A,  Ai](A2){A}  N0  and 

A'  =  ElimfJV',  A(](1V2){1V/}  N' o-  Since  N  and  N'  arc  both  of  type  Kind,  it  follows  that 
N  =  N'.  From  here  we  get  that  No  =  Nf  Since  both  N\  and  N[  have  the  type  Kscm  or 
have  the  type  N  — ►  Kind,  it  follows  that  N\  =  N[.  From  this  we  can  show  that  the  IV*  and 
N'  arc  equal.  Finally  as  above,  we  can  show  that  the  A%  and  the  N'oi  are  equal.  □ 

Theorem  C.3.5  (Confluence)  Let  A  F  A  :  B  and  A  \~  A'  :  B  be  two  judgments.  If  A  — Pn1'  ^  ’ 
then  A  and  A'  have  a  common  redact  -  there  exists  a  term  C  such  that  A  l>  *  C  and  A'  [>*  C. 

Proof  We  know  that  both  A  and  A'  reduce  to  normal  forms  ,4 1  and  A\ .  Due  to  subject  reduction, 
both  A\  and  A\  have  the  same  type  B.  By  the  previous  lemma  A\  =  A\ .  □ 

C.4  Consistency 

Theorem  C.4.1  (Consistency  of  the  logic)  There  exists  no  term  A  for  which  ■  F  A  :  YIX  : 

Kind.  X. 

Proof  Suppose  there  exists  a  term  A  for  which  •  F  A  :  II X :  Kind.  X.  By  theorem  C.2.88,  there 
exists  a  normal  form  B  for  A.  By  the  subject  reduction  •  F  B  :  FLY :  Kind.  X.  We  can  show  now 
that  this  leads  to  a  contradiction  by  case  analysis  of  the  possible  normal  forms  for  the  types  in  the 
calculus.  □ 
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